Attacks on TLS that break the intuitive security property of a virtual recreation of a physically secure channel can be categorized along three dimensions.
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.
Another class of protocol logic flaws are state-machine bugs [Early CCS Attack, SMACK Attack].
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.
Much more seriously, resuming the attacker controlled session on a different connection re-enables the renegotiation attack. This attack is known as the triple handshake attack and is an instance of a larger class of attacks resulting from inadequate channel binding in compound authentication protocols. The miTLS security theorem does not promise channel binding across different connections and is thus not violated by the attack. To be secure, applications making use of miTLS have, however, to be carefully designed to make use of the provided security cues. We give a basic HTTPS client, miHTTPS, as an example for such an application. Subsequently the flaw is also being patched at the TLS level using a new extension.
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 support a stale IV ( encrypt, encrypt). 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 standard mitigation for padding oracles.
POODLE is a padding oracle attack that targets CBC-mode ciphers in SSLv3. It is due to SSLv3 not specifying the contents of the padding
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
real_decrypt function in the RSA module.
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.
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].
SSL 2 is outlawed: miTLS does not support SSL 2.
Vaudenay's attack relies on the attacker being able to
distinguish bad_record_mac and decryption_failed
errors. We implement standard mitigation for padding oracles.
We prevent the renegotiation attack by implementing the renegotiation extension. See the Extensions module and how the Handshake module checks for the extension.
We prevent the alert attack by resetting all buffers on epoch change (that is when we send or receive the CCS message).
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.
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.
The recent attack on RC4 is possible because RC4 is not IND-CPA secure, thus it would be unreasonable to assert its security.
The triple handshake attack and is an instance of a larger class of attacks resulting from inadequate channel binding in compound authentication protocols.
Early CCS Attack and SMACK Attack are prevented as the type-based proof for miTLS guarantees that its state machine conforms to its logical specification.
miTLS does not support any export ciphersuites, and clients prevent Logjam-like attacks by enforcing a minimum strength on Diffie-Hellman groups proposed by servers. Specifically, miTLS comes with a configurable, pre-populated database of whitelisted known groups. When receiving an unknown group from a server, clients perform additional checks. By default, no group with a modulus of less than 1024 bytes is accepted. In addition, miTLS implements a TLS extension proposed in a recent Internet Draft which allows to negotiate one of a number of strong groups.
