Systematic Fuzzing and Testing of TLS Libraries

Somorovsky, Juraj

doi:10.1145/2976749.2978411

Cited by 81 publications

(47 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Many padding oracle attacks have surfaced over the years, ranging from attacks exploiting straightforward issues (such as implementations sending padding error alerts after decryption) to more advanced attacks using side channels (such as Lucky13 [1] or POODLE [40]). Even though padding oracle attacks are well known, they remain difficult to prevent in TLS implementations and new variants tend to appear regularly [48]. The CBC mode of operation is also not secure against chosen-plaintext attacks when the IV is predictable (as in TLS 1.0), which is exploited in the BEAST attack [22].…”

Section: Introductionmentioning

confidence: 99%

Implementing and Proving the TLS 1.3 Record Layer

Delignat-Lavaud

Fournet²,

Kohlweiss³

et al. 2017

2017 IEEE Symposium on Security and Privacy (SP)

View full text Add to dashboard Cite

The record layer is the main bridge between TLS applications and internal sub-protocols. Its core functionality is an elaborate form of authenticated encryption: streams of messages for each sub-protocol (handshake, alert, and application data) are fragmented, multiplexed, and encrypted with optional padding to hide their lengths. Conversely, the sub-protocols may provide fresh keys or signal stream termination to the record layer. Compared to prior versions, TLS 1.3 discards obsolete schemes in favor of a common construction for Authenticated Encryption with Associated Data (AEAD), instantiated with algorithms such as AES-GCM and ChaCha20-Poly1305. It differs from TLS 1.2 in its use of padding, associated data and nonces. It also encrypts the content-type used to multiplex between sub-protocols. New protocol features such as early application data (0-RTT and 0.5-RTT) and late handshake messages require additional keys and a more general model of stateful encryption. We build and verify a reference implementation of the TLS record layer and its cryptographic algorithms in F , a dependently typed language where security and functional guarantees can be specified as pre-and post-conditions. We reduce the high-level security of the record layer to cryptographic assumptions on its ciphers. Each step in the reduction is verified by typing an F module; for each step that involves a cryptographic assumption, this module precisely captures the corresponding game. We first verify the functional correctness and injectivity properties of our implementations of onetime MAC algorithms (Poly1305 and GHASH) and provide a generic proof of their security given these two properties. We show the security of a generic AEAD construction built from any secure onetime MAC and PRF. We extend AEAD, first to stream encryption, then to length-hiding, multiplexed encryption. Finally, we build a security model of the record layer against an adversary that controls the TLS sub-protocols. We compute concrete security bounds for the AES_128_GCM, AES_256_GCM, and CHACHA20_POLY1305 ciphersuites, and derive recommended limits on sent data before re-keying. We plug our implementation of the record layer into the miTLS library, confirm that they interoperate with Chrome and Firefox, and report initial performance results. Combining our functional correctness, security, and experimental results, we conclude that the new TLS record layer (as described in RFCs and cryptographic standards) is provably secure, and we provide its first verified implementation.

show abstract

Section: Introductionmentioning

confidence: 99%

Implementing and Proving the TLS 1.3 Record Layer

Delignat-Lavaud

Fournet²,

Kohlweiss³

et al. 2017

2017 IEEE Symposium on Security and Privacy (SP)

View full text Add to dashboard Cite

show abstract

“…It prepares encrypted packets with specified plaintext or ciphertext (with specified errors) to be sent to the peer at any stage of an SSL/TLS connection. In our implementation, we adopted an open-source tool, TLS-attacker [67]. It is able to complete an SSL/TLS handshake or replace any packet in this process.…”

Section: Differential Analysis Frameworkmentioning

confidence: 99%

“…Unlike GnuTLS, OpenSSL does not have enclave-illegal instructions and can be loaded and ran directly by an SSL/TLS server as sgx.trusted_files in the enclave with Graphene. To complete the attack, we extended the opensource tool, TLS-Attacker [66], and implemented an add-on module. We chose TLS-Attacker because it enables us to easily replace the ClientKeyExchange message with any message we would like the oracle to test.…”

Section: Bleichenbacher Attacksmentioning

confidence: 99%

Stacco

Xiao

Chen

et al. 2017

Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security

View full text Add to dashboard Cite

Intel Software Guard Extension (SGX) offers software applications a shielded execution environment, dubbed enclave, to protect their confidentiality and integrity from malicious operating systems. As processors with this extended feature become commercially available, many new software applications are developed to enrich to the SGX-enabled software ecosystem. One important primitive for these applications is a secure communication channel between the enclave and a remote trusted party. The SSL/TLS protocol, which is the de facto standard for protecting transport-layer network communications, has been broadly regarded a natural choice for such purposes. However, in this paper, we show that the marriage between SGX and SSL may not be a smooth sailing.Particularly, we consider a category of side-channel attacks against SSL/TLS implementations in secure enclaves, which we call the control-flow inference attacks. In these attacks, the malicious operating system kernel may perform a powerful man-in-the-kernel attack to collect execution traces of the enclave programs at the page level, the cacheline level, or the branch level, while positioning itself in the middle of the two communicating parties. At the center of our work is a differential analysis framework, dubbed Stacco, to dynamically analyze the SSL/TLS implementations and detect vulnerabilities-discernible execution traces-that can be exploited as decryption oracles. Surprisingly, in spite of the prevailing constant-time programming paradigm adopted by many cryptographic libraries, we found exploitable vulnerabilities in the latest versions of all the SSL/TLS libraries we have examined.To validate the detected vulnerabilities, we developed a man-inthe-kernel adversary to demonstrate Bleichenbacher attacks against the latest OpenSSL library running in the SGX enclave (with the help of Graphene) and completely broke the PreMasterSecret encrypted by a 4096-bit RSA public key with only 57,286 queries. We also conducted CBC padding oracle attacks against the latest GnuTLS running in Graphene-SGX and an open-source SGXimplementation of mbedTLS (i.e., mbedTLS-SGX) that runs directly inside the enclave, and showed that it only needs 48,388 and 25,717 Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). queries, respectively, to break one block of AES ciphertext. Empirical evaluation suggests these man-in-the-kernel attacks can be completed within one or two hours. duces the TCB of the shielded execution, enabling a wide range of applications [20,36,54,59,65,76].In typical application scenarios [20,36,76], shielded execution does not work completely alone; it communicates with remote trusted parties using secure channels, e.g., SS...

show abstract

“…The identified bugs were classified as state machine bugs and this put the internal state machines of TLS implementations into the focus, next to and on the same level of criticality as the implementation of pure cryptographic functionality. The systematic testing of TLS implementations based on the principles of these kind of state machine bugs with a tool was presented in [32] and offers the user the possibility to create custom TLS message flows and arbitrarily modify message contents. The strategy for testing of TLS implementations via the exchange of modified messages or injection attacks was also followed in [28] and [12].…”

Section: Related Workmentioning

confidence: 99%