A version rollback attack can enable an attacker to make the client and server fall back to a lower SSL/TLS version than the highest one supported and advertised.
This is useful for a couple of reasons.
Maybe to attempt exploiting the weaknesses of a particular SSL/TLS version[1][2][3]. Currently, mainly downgrading to SSL 2.0 would be desirable from attackers’ point of view.
Or, under certain SSL/TLS versions and particular implementations, somewhat weaker cipher suites(for example using a weaker symmetric encryption algorithm) might be available and likely to be selected.
As mentioned, downgrading to SSL 2.0 is desirable from the attackers’ point of view, due to the handshake messages being not protected. This permits a MITM attack to make the client selecting a weaker cipher suite than it would normally choose. [1][2]
Such a cipher suite could use a weak symmetric encryption algorithm(like DES) or export cipher suites, which would enable the attacker to brute force the keys and gain access to the data exchanged between the client and server, recovering possible sensitive information, like passwords or persistent authentication cookies.
Unfortunately on the server side [12], SSL 2.0 is still available today by default; also some browsers(still used in production) enable it by default.
SSL 3.0 itself does not contain major flaws that would make the average user to worry. Virtually any server [12] or client provides, by default support for SSL 3.0; although support for it is not quite a necessity these days(probably still required on the server side, due to clients like Internet Explorer 6).
SSL 3.0 and TLS 1.0 are somewhat similar(from a security point of view mainly the key derivation function is a weaker point for SSL 3.0, and TLS uses HMAC for MACs compared to SSL 3.0), most of the servers [12]or clients provide, by default support for TLS 1.0.
TLS 1.0 and TLS 1.1 also are similar(from a security point of view explicit IVs were added to TLS 1.1 to prevent some CBC attacks reported), the difference between TLS 1.0 and TLS 1.1 is smaller compared to the one between SSL 3.0 and TSL 1.0.
TLS 1.1 is not widely used as writing. From the modern browsers, Opera enables it by default. And Apache with mod_gnutls is known for having it enabled by default. Both have a small market share. Some servers, like IIS 7.5, or browsers, like IE8 on Windows 7, support TLS 1.1 but disable it by default.
TLS 1.2 compared with TLS 1.1 provides more security, for example if we take into account the changes made to the PRF and the key derivation process or the replacement of the MD5/SHA-1 combination in the digitally-signed element [4].
TLS 1.2 support on the server side in production is practically inexistent [12]. Again from the modern browsers, Opera enables it by default. Some servers, like IIS 7.5, or browsers, like IE8 on Windows 7, support TLS 1.2 but disable it by default.
(Secure) fallbacks within the protocols themselves
The protocols(excluding SSL 2.0) enable the client and server to (securely) select and use the highest version available between them.
For example a client supports TLS 1.0 and TLS 1.1, and advertises support for TLS 1.1(Client Hello, handshake version), while the server only supports TLS 1.0 and replies (correctly) with TLS 1.0 Server Hello. For the client this is acceptable, since it supports TLS 1.0 too.
SSL 3.0 and TLS versions offer protection for version rollback attacks with the Finished message(basically a hash over the handshake messages is used in the process, modifications to the handshake messages would cause the parties to not accept each others' Finished messages).
Also in case RSA is being used for key agreement and authentication, the client generates a 48-byte premaster secret, and the version number in the PreMasterSecret is the version offered by the client in the Client Hello, not the version negotiated for the connection. The server will verify this value.
Some have questioned the need for such an extra protection [11].
And in the past it has been reported that some servers expect the negotiated version to be used in the PreMasterSecret, not the version used in the Client Hello and such a server terminates the connection [9]; or that some servers don't check the version in an RSA "ClientKeyExchange" [10].
Also, it’s interesting to note that some theoretical attacks have been described regarding a TLS server that reveals whether a particular message, when decrypted, (among others) has the correct version number [8].
For the TLS 1.1/TLS 1.0 example from above(with RSA for key agreement and authentication) the client will use 0x0302 for the version number within the PreMasterSecret.
Actually we have an easy way to see this, with gnutls_cli or gnutls_serv put into debug mode with the -d option(other variant would be to use Wireshark and OpenSSL).
Say we enter:
gnutls-cli --priority NONE:+VERS-TLS1.1:+VERS-TLS1.0:+NULL:+RSA:+AES-128-CBC:+SHA1:+COMP-NULL www.carbonwind.net --insecure -d 9
Which translates into sending this Client Hello:
The server replies with the highest TLS version it supports, TLS 1.0:
And within gnutls_cli output we can spot the decrypted PreMasterSecret, note from there that 0x0302(indicating TLS 1.1) is used for the version number from the PreMasterSecret:
In case of a SSL 2.0 compatible SSL 3.0 or TLS(either 1.0/1.1/1.2) Client Hello, a possibility of version rollback appears, fallback to SSL 2.0(assuming the server supports it too), due to the handshake messages being not protected.
To counter such an attack, when SSL 3.0 or TLS client are in SSL 2.0 compatibility mode, they must use a special PKCS#1 block formatting for the RSA encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY. This is done so that SSL 3.0 and TLS servers will reject SSL 2.0 sessions with SSL 3.0 and TLS capable clients.
We can analyze this with Wireshark and OpenSSL.
For example, say we have the following SSL 2.0 compatible TLS 1.0 compatible Client Hello(IE6 is the client with SSL 2.0/SSL 3.0/TLS 1.0 enabled).
We don’t have to simulate an attack on the server side, just make OpenSSL s_server reply with SSL 2.0 Server Hello, something like:
openssl s_server -accept 443 -cert my cert -ssl2 -www
Of interest is the handshake message Client Master Key, more exactly the Encrypted Key field.
First we export the content of this field, say into a file named a.
This content is encrypted with the server’s public RSA key, key contained within its certificate.
We can decrypt it using the server’s private key.
For that we can use openssl rsautl [6].
For example, if we enter something like this:
openssl rsautl -decrypt -inkey srv.key -in a -out a.txt -hexdump
we can visualize the decrypted content of the Encrypted Key field. But we are not particularly interested in that.
openssl rsautl has a -ssl option, for the special padding used in SSL 2.0 backwards compatible handshakes.
If we try that, see the error it throws, from which useful for us is to note that the client used the special padding to denote it’s a TLS 1.0 speaker:
Modifications to the original versions of the protocols
Modifications to the original versions of the protocols, for example the proposed False Start draft, has been reported to introduce limited version rollbacks [7].
Compatibility fallback mechanisms in browsers
Although the protocols enable the client and server to use the highest version available between them, quite some time ago, browsers, due to compatibility issues introduced their own fallback mechanisms.
Such browsers’ fallback mechanisms make useless the protections offered by the SSL/TLS protocols against version rollbacks.
Fallback mechanisms are in place as writing on modern browsers.
For example, the latest stable version of browsers like Chrome, Firefox, Safari, Opera or Internet Explorer can fallback from TLS 1.0 to SSL 3.0, simply by RST-ing or FIN ACK-ing the TCP connection on the server side upon receiving the browser’s TLS 1.0 Client Hello; after this unsuccessful attempt the browser will retry with a SSL 3.0 Client Hello.
For an attacker with active MITM capabilities is trivial to trigger the browser’s fallback mechanism.
To understand why such a mechanism is needed, enable TLS 1.1 and TLS 1.2(SSL 3.0 and TLS 1.0 are enabled by default) within IE8 on Window 7 and try to visit certain Microsoft domains, you may fail since the TLS 1.2 Client Hello is rejected by the server(flawed implementation) instead of having the server reply with a TLS 1.0 Server Hello and IE8 will not try to fallback to a TLS 1.0 Client Hello message(basically in this configuration IE8's fallback mechanism does not seem to kick in).
To particularly note that the Schannel implementation(for the latest Schannel version), either on client or server side, offers a limited (somewhat weaker) set of cipher suites for SSL 3.0 compared with TLS 1.0 [13].
Although the explanation provided within [13] is a personal interpretation of RFCs, assuming no weak cipher suites(export one or symmetric encryption algorithms with 56-bit keys) are offered(thus no chance to be selected), for the average user the fallback (triggered by an attacker using the browser’s fallback mechanism) from TLS 1.0 to SSL 3.0 is not significant, although not desirable.
There is a browser, still used in production, that would “worth” a mention, IE6.
By default IE6 uses SSL 2.0 and SSL 3.0(TLS 1.0 is disabled), with a SSL 2.0 compatible SSL 3.0 Client Hello. To make it worst, IE6 uses weak SSL 2.0 cipher suites by default.
Above we saw IE6 using the special PKCS#1 block formatting for the RSA encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY to indicate to the server it was a native TLS 1.0 speaker to counter a version rollback MITM attack.
This time we will kick in IE6’s fallback mechanism, make it fall back from a SSL 2.0 compatible SSL 3.0 Client Hello to a “pure” SSL 2.0 Client Hello, thus making the server unaware that IE6 is a SSL 3.0 speaker, since the special padding will not be used anymore.
For this test we can use OpenSSL s_server like so:
openssl s_server -accept 443 -cert my cert -cipher SSLv2 -www
IE6 will send its SSL 2.0 compatible SSL 3.0 Client Hello.
When the server receives this message, it will issue a Handshake Failure fatal alert(actually just a FIN ACK will do) and will terminate the connection.
After this unsuccessful attempt IE6 tries with a pure SSL 2.0 Client Hello, see bellow:
At this point the attacker, for example, is free to influence the cipher suite selection, the connection’s security depending on the server’s SSL 2.0 enabled cipher suites(hopefully it has no weak ones).
When the browsers are friendly MITMed
Currently, at the corporate level, there is a common practice of using intercepting HTTPS forward web proxies, basically such proxies do active SSL/TLS MITM creating on-the-fly certificates for the requested servers, certificates signed by the proxies with their own CA certificate(either root or subordinate), this CA certificate being trusted by corporate clients.
Two SSL/TLS session exist, one between the browser and the MITM HTTPS web proxy, and the other between the MITM HTTPS web proxy and the server.
Due to the MITM HTTPS web proxy controlling the SSL/TLS sessions:
- on the good side, the MITM HTTPS web proxy can turn off the browsers’ fallback mechanism and enforce the use of certain TLS versions(say only TLS 1.0 and above) and strong cipher suites.
- on the bad side, the MITM HTTPS web proxy using a careless implementation can use its very own fallback mechanism, possibly negotiate a weaker SSL/TLS version(and cipher suite) with the server than the browser itself would negotiate.
A MITM HTTPS forward web proxy is described in [14].
Although this uses a SSL 2.0 compatible TLS 1.0 Client Hello, will not allow the negotiation of a weaker SSL/TLS version with the server than the one negotiated between itself and the browser. In fact it can upgrade the SSL/TLS version, say use TLS 1.0 between itself and the server while SSL 3.0 is used between itself and the browser.
References:
[1] Prohibiting SSL Version 2.0
http://tools.ietf.org/html/draft-ietf-tls-ssl2-must-not-04
[2] Analysis of the SSL 3.0 Protocol
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.64.660&rep=rep1&type=pdf
[3] Prohibiting SSL Version 3.0 and Earlier
http://tools.ietf.org/html/draft-turner-ssl-must-not-01
[4] TLS 1.2 RFC Major differences from TLS 1.1
http://tools.ietf.org/html/rfc5246#section-1.2
[5] TLS 1.1 RFC Differences from TLS 1.0
http://tools.ietf.org/html/rfc4346#section-1.1
[6] openssl rsautl
http://www.openssl.org/docs/apps/rsautl.html
[7] Random SSL/TLS 101 - False Start
http://www.carbonwind.net/blog/post/Random-SSLTLS-101-False-Start.aspx
[8] TLS 1.2 RFC RSA-Encrypted Premaster Secret Message
http://tools.ietf.org/html/rfc5246#section-7.4.7.1
[9] Client side interoperability experiences for the SSL and TLS protocols
http://tools.ietf.org/html/draft-pettersen-tls-interop-experience-00
[10] Unfortunate current practices for HTTP over TLS
http://www.ietf.org/mail-archive/web/tls/current/msg07281.html
[11] When/why is the RSA premaster secret version rollback check needed?
http://www.ietf.org/mail-archive/web/tls/current/msg06846.html
[12] Internet SSL Survey 2010
http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf
[13] AES is not a valid cipher for SSLv3
http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx
[14] A brief look at the SSL/TLS settings(behavior) of the Outbound HTTPS Inspection on Forefront TMG 2010 RC
http://www.carbonwind.net/blog/post/A-brief-look-at-the-SSLTLS-settings(behavior)-of-the-Outbound-HTTPS-Inspection-on-Forefront-TMG-2010-RC.aspx