A Zoo of TLS attacks

Attacks on TLS that break the intuitive security property of a virtual recreation of a physically secure channel can be categorized along three dimensions.

  1. Protocol logic vs. cryptographic design flaw
  2. Specification/Standard vs. Implementation errors
  3. TLS vs. Context

Flaws in the protocol logic

Attacks targeting the protocol logic may for instance cause the client and server to negotiate the use of weak algorithms even though they both support strong cryptography.

If the faulty negotiation logic conforms to the specification, then the attack is on the specification itself (as, e.g., partially enabled by the False Start modification), if an implementation deviates from the specification to implement a faulty negotiation logic [Dimcev, Langley] it is an attack on the implementation. As many aspects of the standard can be underspecified or ambiguous, it is not always possible to distinguish between these two cases.

The attack can also be either an attack on TLS proper, or on its context, e.g. if the attacker can just change the configuration files to deactivate strong cryptography. As the TLS standard does not describe APIs or configuration file formats, context specific attacks are always implementation specific.

The renegotiation attack [TLS_Reneg_Attack] is a logical attack on the TLS standard, where one peer believes it is running the first handshake on a connection, while the other peer is running a re-handshake. miTLS prevents the renegotiation attack by implementing the renegotiation extension.

More generally, the TLS specification is vague about how applications should handle data coming from consecutive sessions, e.g. whether it is safe to join them and consider them as a single stream, or if the user should be notified of the change of context. The renegotiation extension partially fixes the problem, but it still leaves room for our alert attack, where the attacker can turn any authentic fatal alert into a warning alert, which gets ignored by default.

Cryptographic design flaws

Attacks exploiting cryptographic design flaws may simply result from cryptanalytic progress against the cryptographic building blocks of TLS. They can, however, also result from improper non-blackbox use of otherwise secure cryptographic constructions. An example for this is chosen ciphertext chaining (CBC) mode encryption. Early versions of TLS allow using knowledge of the next initialization vector (IV) to set up adaptive plaintext attacks, see, e.g. OpenSSL archive for a first mention of the 'BEAST attack'. The vulnerability is still present in the code, as we implement the standard faithfully. See how in Enc we use a stale IV. The attack can be prevented by sending empty fragments. As this example shows, the distinction between protocol logic and cryptographic flaws is ambiguous as protocol logic can enable, as when giving the attacker access to the IV of future encryptions, or prevent cryptographic attacks, as in the empty fragment counter measure.

Similarly, padding-oracle attacks, use a combination of protocol logic and cryptography, taking advantage of error messages to gain information on encrypted data [Vaudenay02, CanvelHVV03]. Vaudenay's attack relies on the attacker being able to distinguish bad_record_mac and decryption_failed errors. We implement separate error messages for SSL 3.0 and TLS 1.0, but uniform error messages for TLS 1.1 and TLS 1.2.

Padding-oracle attack and similar attacks, through which the attacker can obtain a (partial) decryption oracle, can often be traced back to logical or cryptographic mistakes in the standard. Once the standard describes a countermeasure, which might however be hard to implement, e.g. identical timing for success and error branches, the onus is shifted to implementations. One example for this is the [Bleichenbacher] attack, for which the countermeasure prescribed by the standard is to use a freshly sampled random pre-master secret if pre-master secret decryption fails. A variant of the Bleichenbacher attack is the [KlimaPR] attack. Here is code for testing whether a TLS implementation is susceptible to the Bleichenbacher or KlimaPR attack. Our code is not, as we implement the recommended counter measure of continuing with a random key in case of a decryption error. See the decrypt_int function in the RSA module.

Implementation flaws

More typical implementation attacks are buffer overflows [OpenSSL vulnerabilities] resulting from programming errors, or timing-based side channel attacks against cryptographic primitives [BrumleyB]. The former are largely prevented as we use a save language. The latter are outside our model, and we rely on the proper implementation of core cryptographic algorithms by the Bouncy Castle library that we rely on.

Configuration flaws, infrastructure flaws

Further attacks arise from the usage or configuration of TLS, rather than the protocol itself, for instance exploiting poor certificate management or gaps between TLS and the application logic [Lawall10, Most dangerous code].

Example attacks prevented in miTLS

SSL 2.0 version rollback [1996]

SSL 2 is outlawed: miTLS does not support SSL 2.

Padding oracle attack by Vaudenay [2002]

Vaudenay's attack relies on the attacker being able to distinguish bad_record_mac and decryption_failed errors. We implement separate error messages for SSL 3.0 and TLS 1.0 but uniform error messages for TLS 1.1 and TLS 1.2.

Renegotiation attack by Ray [2009]

We prevent the renegotiation attack by implementing the renegotiation extension. See the Extensions module and how the Handshake module checks for the extension.

Alert attack [2012]

We prevent the alert attack by resetting all buffers on epoch change (that is when we send or receive the CCS message).

Compression-based attacks [2012]

In ProvPriv 2012, and the CRIME attack, TLS-level compression is used to break confidentiality. miTLS does not support TLS-level compression, and provides a length-hiding API to let the application conceal the real plaintext length into a chosen range of possible lengths.

Timing attacks [2013]

The recent Lucky13Attack demonstrates that input-output IND-CPA security is not sufficient to prevent all practical attacks. While we do not formally model time we plan to implement countermeasures both by carefully avoiding timing channels in the implementation and by an extension discussed in paper and RFC draft.

Attacks on RC4 [2013]

The recent attack on RC4 is possible because RC4 is not IND-CPA secure, thus it would be unreasonable to assert its security.