Google have announced on their online security blog that they will be shortly dropping support for the obsolete SSL 3.0 protocol. A write up of the vulnerability is available, and has been designated CVE-2014-3566 (though the CVE data remains sealed at the time of this writing). The vulnerability can be addressed by disabling the support for SSL 3.0 or more specifically the CBC (Cipher Block Chaining) support in SSL 3.0.
The problem lies in the backwards compatibility fallback of TLS, which permits renegotiation to a lower level if the conversation cannot be completed. Whilst both a client and a server may support the current version of the TLS protocol (1.2, as of the time of writing), errors in the communication can result in the browser and server renegotiating at a lower level. TLS 1.0 which was a successor to SSL (originally implemented in Netscape Navigator which was announced twenty years ago this week). The implemenation of TLS 1.0 permitted the fallback to SSL 3.0, which supports encryption now known to be fallable. Newer releases of TLS have banned certain ciphers – for example, TLS 1.1 removed support for some CBC attacks eight years ago, whilst the next version of the specification TLS 1.3 has removed all support for CBC and RC4 ciphers.
The specific attack takes place in two parts; first, through packet injection a connection can be reset by a MITM attack on the client and server during connection set-up, after which the server and client can be forced to renegotiate to a lower level (such as SSL 3.0). Once this is done, attacks described in the paper as the Padding Oracle on Downgraded Legacy Encryption attack result in certain parts of the key being leaked during the conversation. SSL 3.0 uses either the RC4 stream cipher (which was already known to have vulnerabilities) or a block cipher in CBC mode. The latter is now known to be suspect, and since these are the only two modes of security provided by SSL it should be avoided. The attack works by being able to analyze the last byte in a the block cipher by sending up to 256 packets to the server which only differ in the last byte of the first block. Of these reqeusts, the server will reject all of them except when the byte is known to be correct, which will leak one byte of information. By moving the entire sequence by one byte (say, by appending a character onto the end of the path request) the attacker is thus able to deduce an arbitrary number of bytes in the payload, which can potentailly leak the value of a cookie protected by the SSL layer.
For systems that cannot easily disable SSL 3.0 support, TLS has an option when connecting to disable such downgrades automatically using the TLS_FALLBACK_SCSV option. The client can then determine if it needs to go ahead and perform a retry with a lower connection instead of it being an automated part of the TLS handshake.
This discussion is also pertinant to the on-going development of HTTP/2, which is in final call at the moment. Issue 612 describes changes to a controversial section 9.2.2 places limits on which ciphers can be used with HTTP/2 connections, which in earlier versions of the draft placed an additional negotiation on top of TLS to determine which ciphers were valid or not. The section specifically calls for connections over CBC mode to be disabled by default, even if the underlying TLS connection has already been made with a version that is otherwise acceptable to both client and server. Last week, there were concerns that there could be information leakage in the first 256 bytes of the connection which appears to have driven Google to publish the attacks and remove SSL 3.0 as a way of protecting the environment, even if HTTP/2 itself is not going to be able to place additional requirements on the TLS libraries.
Although progress has been made, it's still causing problems with some on the working group, including Roy Fielding describing an application protocol embedding security requirements as insane and actively announcing not to support 9.2.2 and the author of Jetty (Greg Wilkins) claiming that it is impossible to implement in a future proof way, along with Apple's Michael Sweet saying that it may not be possible to implement 9.2.2 for the ~900million iOS and OSX devices as well as Microsoft's vote against the proposal.
By removing SSL 3.0 and the legacy CBC mode which is known to be vulnerable, Google hopes to both secure browser-server connections (which have been using TLS 1.2 for some time) as well as mitigating against an attack that might be possible if the connection is attacked. It may be that this unlocks the block in the HTTP/2 specification and permits it to depend on TLS 1.2 or above, which with the TLS 1.3 specification due out next month (which also blocks the CBC modes) may be enough to move HTTP/2 forwards. Otherwise we are left with this summary:
| AFAIK, 9.2.2 with proposed modifications plus server operating on | blacklist instead of whitelist is not fragile. So long as the client uses a whitelist and so long as the server operates on a black list and so long as the server can actually influence cipher selection and so long as it bans any cipher matching the 3 patterns you provided and so long as cipher names never differ from those patterns and so long as no additional patterns are configured. I think you just defined fragile.
