Few things can be kept secret within computer security, and it has been the case with a flaw in SSLv3, where there were rumours of a forthcoming announcement. So it happened on Tuesday 14 October 2014 that Bodo Möller (along with Thai Duong and Krzysztof Kotowicz) from Google announced a vulnerability in SSLv3, and where the plaintext of the encrypted content could be revealed by an intruder. The flaw itself has been speculated on for a while, and this latest announcement shows that it can actually be used to compromise secure communications.
The vulnerability was discovered last month, and named POODLE (Padding Oracle On Downgraded Legacy Encryption) attack, and it relates to the method that Web servers deal with older versions of the SSL (Secure Socket Layer) protocol.
Secure Sockets and Tunnelling
Figure 1 outlines how network protocols fit together, where we use insecure protocols such as HTTP, TCP and IP to communicate with a Web site. Each of these protocols were designed at a time when security was not an issue on systems. The fix to improve security was to insert a layer between the network layer (IP) and the transport layer (TCP), and is named SSL. This later secures the upper level protocol, and creates a secure and encrypted tunnel between the client and the Web server, so that no-one can crack the communications for the connection.
Figure 1: Networking stack with SSL integration
There are several different versions of SSL, from 1.0 to 3.0 , and with 3.1 it changed its named to TLS (Transport Layer Socket), so that SSL 3.1 is also known at TLS 1.0. Most systems now use TLS 1.1 or 1.2, and which are free of flaws which compromised previous versions.
SSL (as illustrated in Figure 2) works by the client telling the server which type of encryption it would like to use (such as RC4) and the other cipher parameters it can support. The server replies back with its preferred cipher scheme, along with its digital certificate. This digital certificate contains its public key, and the proof of its identity. The client then creates a new session key for the encrypted tunnel, and then encrypts this with the public key provided by the server. It then sends this to the server, where the server decrypts it, and thus has the same encryption key as the client. After this, the client and server can communicate with the session key (and the chosen encryption method) – thus creating a tunnel between themselves. This tunnel should be almost impossible to crack, as it uses a session key, which would take a long time to crack through brute force.Figure 2: Outline of SSL tunnelling
Within SSL, most servers will cope with previous versions of the protocol, and will downgrade from TLS 1.0 to SSLv3 if the handshake between the client and the server fails. The intruder will thus refuse a TLS 1.0 version, and go for an SSLv3 method, where they will be able to decipher the communciations. In the following example, we force the connection to the Google Web site to use an SSLv3 connection (with the -ssl3 option):
billbuchanan@Bills-MacBook-Pro:~$ openssl s_client -connect www.google.com:443 -ssl3 CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIEdjCCA16gAwIBAgIISVyALWN+akUwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UE BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl --- missed out content fsX5GyPM24FrA9G3tbBOrDBrclbG8tBhSS+yIS2e4D3WpVrqiYDr9YqOmpD8jXWH SOx4I5L0D0jZYqKfJuImGcFwdIETq0EpCmkhJfGNHjVdzC/h/T61TmaY -----END CERTIFICATE----- subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 --- No client certificate CA names sent --- SSL handshake has read 3578 bytes and written 299 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 Cipher : ECDHE-RSA-RC4-SHA Session-ID: F220B72DE15D22EB0AE909DBF25C1731FEE98B4D77E5AB123A6648425DADA398 Session-ID-ctx: Master-Key: B3CB1EA901EEFCA6A2017E3C3E7DDBB5037FA171D20886A6C25C481D008F23535D2345E7E274704C1398ED138D05C6BD Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1413353089 Timeout : 7200 (sec) Verify return code: 20 (unable to get local issuer certificate)
The problem around SSLv3 has been around for a while, and many in the industry professionals have been recommending that administrators do not allow its usage.
The flaw is not a Heartbleed-type issue, which caused major compromises across the Internet. Overall it is basically highlighting a previously defined flaw. A more pressing issue with SSL/TLS is Man-in-the-Middle attacks, and where an intruder can get in-between the client and the server (using a proxy connection). The fix for POODLE is simply for administrators to disable SSLv3 on their Web sites, in order to avoid the downgrade of the secure connection. Even still, it’s not a major problem, as the intruder is just reading their own data.
A video lecture on SSL/TLS will appear here later today.