On Tuesday, October 14th 2014, Google published details about a vulnerability in the design of SSLv3 that was found by Bodo Möller, Thai Duong and Krzysztof Kotowicz (all Google). The vulnerability allows a Man-in-the-middle (MITM) attacker to recover the plaintext from an encrypted network connection.
If the client and the server both support higher versions than SSLv3, the attacker also has to perform a protocol downgrade attack. This attack uses the fact that, when a connection fails, SSL/TLS clients try re-establishing an encrypted connection with a lower protocol version. This behavior was added to deal with faulty servers which cannot deal with recent TLS versions and misbehave by, e.g., just closing the connection when a client tries to use a TLS version they do not support.
Current TLS version use
To judge the impact that this vulnerability has, we use connection data from the ICSI SSL Notary to estimate how SSLv3 is still being used in the wild at the moment.
For our analysis, we looked at the 12,795,585,451 connections that were observed by the Notary in the last 2 months. For each of the connections, we examine which SSL/TLS version was used. The results are summarized in the following table:
As we can see, during the 2 month period 73,843,197 (0.6%) of the observed connections use SSL version 3. The connections are established to 80,454 different servers, which is 9% of the total servers we saw during these 2 months. We also saw TLS connections to most of these servers. There were just 6,532 servers where we only saw SSLv3 and no TLS connections being established. These servers thus probably do not support TLS at all.
Mitigation and TLS_FALLBACK_SCSV
There are two ways to mitigate this issue. The first, probably preferable way, is to completely disable SSLv3 support on clients and on servers. The second method is to support
This proposal prevents the aforementioned protocol downgrade attacks by defining a Fallback Signaling Cipher Suite Value (SCSV). This value is sent by clients in their
client hello message when retrying a connection with a lower protocol version after a previous connection attempt failed. When a server supports the proposal, it will reject any connection containing the SCSV when the protocol version is lower than the highest protocol version that it supports.
To illustrate this in an example: Browser A tries to connect to server S using TLS 1.2. The server resets the connection and A tries to connect again, this time using TLS 1.1 sending
TLS_FALLBACK_SCSV in its client hello. This time, the connection succeeds. Since S only supports TLS up to 1.1 it accepts the connection. If S would also support TLS 1.2 it would assume that a protocol downgrade attack is in progress and reject the connection.
Since the SCSV is only sent when a client already downgraded the protocol version, we cannot use our data to determine how widespread adoption of it is. However, Google Chrome, which has quite a bit market share at the moment has supported
TLS_FALLBACK_SCSV since February, we can use our data for an educated guess of how often this fallback is currently needed in the wild.
Looking at our 2 months of data revealed just 334,075 connections that set the signaling value. This equals to less than 500 connections per hour over the more than 100,000 users of our data providers. Hence, since it is probable that Firefox and other big browser vendors will add support for SCSV in the near future, monitoring your network for high connection rates that use it might expose attacks that are in progress.