Schneier on Security

martinr • September 28, 2011 8:54 PM

A couple of comments.

I like Eric Rescorla’s writeup about the BEAST attack:
http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html

The BEAST attack exploits predictable IVs for future SSL records of the same connection for TLS cipher suites with block ciphers in CBC-modes in SSLv3 and TLSv1.0. This is possible because of the “running IV”, i.e. reuse of the last cipherblock from the previous SSL record as initial IV for a new SSL record. And all what BEAST succeeds in doing is recovering blocks of plaintext by lots of guessing (trial and error), BEAST does not recover any encryption keys.

A prerequisite for the BEAST attack is that your Browser will happily execute arbitrary malware of the attackers choice (Man-in-the-Browser attack) allowing that malware to send arbitrary requests to any attacker-chosen Web Servers and where the Browser will obediently insert allegedly confidential existing Cookies into the header of each request performed by the malware. Really, this is a “you are p0wnd” prerequisite, so it is just mildly interesting that the Browser did not serve that Cookie to the malware on a golden platter as well. But I hope it helps to remind folks that lightheartedly mixing and matching untrustworthy code with sensitive data in protocols may have unintended consequences on confidentiality, and it is a bad idea to make bold assumptions about properties of protocols beyond their design limits.

Quoting the TLSv1.2 spec: http://tools.ietf.org/html/rfc5246#page-16

Any protocol designed for use over TLS must be carefully designed to
deal with all possible attacks against it. As a practical matter,
this means that the protocol designer must be aware of what security
properties TLS does and does not provide and cannot safely rely on
the latter.

SSLv3 and TLSv1.0, with their running IV for cipher suites with block ciphers in CBC mode provide an “encryption oracle” (enabling a “chosen plaintext attack”) when supposedly confidential data is mixed with arbitrary data from an attacker, and the attacker is allowed to watch SSL records on the wire before submitting new data that will be transmitted at the beginning of new SSL records on this very connection.

Different TLS connections (even when resumed from the same cached TLS session) and even both directions of the same TLS connection use distinct encryption and MAC keys, so they’re isolated from each other.

The distortion that TLSv1.1 adds with the use of explicit IVs for each new TLS records should provide a sufficient security margin for this kind of attacks, but the security margin depends on the ciphers block size rather than its key size. A non-predictable IV distorts the output of a “CBC encryption oracle” against chosen plaintext attacks. Fortunately the SSL records use a MAC for integrity protection inside the CBC-encryption as an integral part of the protocol, or the explicit IV prepended to the ciphertext could have created a “CBC decryption oracle” in return.

As far as Authentication cookies are concerned — these aren’t “valuable secrets on their own” but rather a means for a specific purpose (limit who can submit a request that will be executed under an existing session). So with respect to what BEAST did in the PayPal attack (it uncovered the plaintext of an SSL-Cookie that was silently assumed not to be accessible to malware running in the browser), there is really nothing that it gained from that particular attack and could not have done directly and without the attack: submitting requests that are executed under the session identified by that SSL-cookie. Would BEAST directly submit evil requests, then the server would have not the slightest indication that it is being attacked. BEAST’s guessing attack itself is noticable heuristically on the server from its amount of network traffic and traffic characteristic (a high number of strange requests with lots of small, dribbling SSL records containing fairly random binary junk).

martinr • September 30, 2011 12:16 PM

btw. this would be one possible mitigation for SSLv3 and TLSv1.0:
http://src.chromium.org/viewvc/chrome?view=rev&revision=97269
OpenSSL has been able to do this for years with empty (instead of one-byte) SSL records, but “empty” is a real border case that might face more interop problems than a prepended fragment of 1 byte.

It is important to do this only for application data records (and it is only necessary for application data records), because a large number of the installed base of TLS implementations will abort the connection when faced with fragmented handshake messages, e.g.:
http://support.microsoft.com/kb/2541763

This solution incurs some additional overhead (slightly more on the receiver), because of the additional TLS record that needs to be processed, and is only necessary for SSLv3&TLSv1.0. Although the TLS protocol has always explicitly stated that message boundaries will not be preserved by the record layer
http://tools.ietf.org/html/rfc2246#section-6.2.1
there might exist a few brittle application designs that choke on such a newly imposed additional fragmentation of application data.

martinr • October 1, 2011 8:55 PM

@jouy: The BEAST attack is all and only about malware in the browser. Malware that can be entirely remote controlled by the attacker. And that malware requires a feedback loop from a ccoperating network monitor in order to make the attack adaptive, i.e. trickle out a new SSL record on the established TLS connection where the Cookie had been sent, read the SSL record on the network to learn the last ciphertext from it and calculate the next “guess” to make it an adaptive chosen plaintext attack. If it was just about sending requests, then there would not be any advantage for SSLv3/TLSv1.0 over TLSv1.1.