TLS 1.2 allows stronger hash functions like SHA-256 and SHA-512, but also supports MD5. So, if a man-in-the-middle attacker can trick the client to authenticate with a server under his control, he can then impersonate that client to the real server by negotiating MD5 hashing and using what the INRIA researchers call a transcript collision attack.
"We find that the TLS libraries in Java (SunJSSE) and on Akamai Servers support RSA-MD5 signatures for both client and server authentication," the INRIA researchers said in a blog post that explains their findings. "Even implementations that do not advertise support for RSA-MD5, such as NSS (before version 3.21), BouncyCastle (Java before version 1.54, C# before version 1.8,1), PolarSSL/mbedTLS (before 2.2.1), GnuTLS (before version 3.3.15), and OpenSSL (before version 1.0.1f) surprisingly accept RSA-MD5 signatures."
The researchers determined that to find a collision for a client impersonation attack on TLS, the attacker would need to compute 2^39 hashes, which is quite practical and would take several hours on Amazon EC2 instances. In fact, during their proof-of-concept attack, they found the collision is just one hour using a workstation with 48 CPU cores.
Another attack that the researchers demonstrated is credential forwarding. This defeats a mechanism known as tls-unique which binds credentials to the TLS channel used to transmit them. This means that a man-in-the-middle attacker shouldn't be able to capture credentials from a TLS connection and relay them to a legitimate server in order to authenticate, because that would open a different TLS channel.
Channel binding with tls-unique is used in SCRAM, the default authentication protocol for XMPP (Extensible Messaging and Presence Protocol); Token Binding, which is designed to protect HTTP cookies and OAuth tokens; and the FIDO universal authentication framework.
A generic collision that could defeat channel binding would require 2^48 keyed-hash message authentication code (HMAC) computations, the researchers found. In their proof-of-concept attack, they found the collision in 20 days on a workstation with 4 Nvidia Tesla GPUs, but they believe the time can be significantly reduced with parallelization across many more GPUs.
Attacking TLS server authentication, which is what's used in most HTTPS (HTTP Secure) implementations, is also theoretically possible, but fortunately it's much harder than attacking client authentication. That's because the server signature does not cover the whole handshake transcript, at least in TLS 1.2.
That's good news, because according to Internet scans, 30 percent of HTTPS servers are currently willing to send RSA-MD5 server signatures and are theoretically vulnerable. If the attack would have been more practical, it would have been devastating to Web security.
Due to these findings, the editors of TLS version 1.3, which is currently only a draft, have removed all use of MD5 signatures from the protocol. OpenSSL, Mozilla NSS, GnuTLS, BouncyCastle, PolarSSL/mbedTLS already have patched versions available that disable the use of such signatures. Oracle Java clients will be fixed in the next critical patch update.
Sign up for CIO Asia eNewsletters.