 |
There are a number of TLS protocols vulnerabilities that have been discovered in recent years. Of those there are three that can and should be prevented by design: Renegotiation Attack, Triple Handshake Attack and CRIME. The Renegotiation and Triple Handshake Attacks both rely on failures in the design of the renegotiation feature. The original Renegotiation Attack was possible because the initial ‘Client Hello’ was indistinguishable from a renegotiation ‘Client Hello’. Therefore, an attacker could make a connection to a server and then later replay the real handshake messages. A new TLS extension standard was required to fix this. The alternative fix is to disable the renegotiation feature. The Triple Handshake Attack is possible because the master secret (used to generate the keys and IVs) is derived from the pre-master secret, client random, and server random. An attacker can engineer these values to be the same for two handshakes when they are the Man-in-the-Middle. A new TLS extension is proposed, and still not standardized, that will prevent this attack by adding a hash of some of the handshake messages to the master secret. If the renegotiation feature is disabled then the attack is not possible as the attacker cannot have the client and server renegotiate into a new, client authenticated TLS connection. One permanent fix for these attacks is to remove renegotiation completely. Unfortunately, there are valid use cases that rely on renegotiation. One example has the client certificate presented in the renegotiation handshake. Not using a client certificate in the initial handshake allows the web server to promptly return pages, then, when a page requires client authentication, the connection is renegotiated and presenting a client certificate is mandatory. Alternatives, like re-keying and client-initiated client authentication, are under development. TLS 1.3 is likely to remove renegotiation and be secure by design. The CRIME attack relies on information leakage when similar sets of messages are compressed by TLS. The very thing that makes compression useful, the minimization of duplicate data, is the key to this attack. If the attacker introduces extra plaintext then the compressed message will grow – until duplicate bytes are seen. By careful placement of the extra plaintext, secret data (like cookies) can be derived. The only sure way of protecting against CRIME in TLS is to disable compression. Therefore, TLS 1.3 will also not negotiate compression algorithms and be secure by design. There are many much needed protocol fixes, like removing compression and fixing renegotiation, expected in TLS 1.3. It’s time for a new protocol that is secure, by design, against these old vulnerabilities! The post Secure Crypto: Leaving Insecurity Behind appeared first on Speaking of Security - The RSA Blog and Podcast. |
|
|
