Do we need to FREAK out? Understanding the SSL/TLS Vulnerability

Information about yet another attack on TLS/SSL has been going around the net for a couple of days now. As is common in the series of attacks we have seen in the last year the new attack comes with a cute name; in this case FREAK- derives from ‘Factoring attack on RSA-EXPORT Keys’. The basic idea behind the attack is covered in a number of other places, so here I would like to outline the How, Why, and What needs to be done to get these FREAKing out attacks out of our systems;

When agreeing a TLS session the client and the server need to agree on what encryption algorithms to use. A specific set of encryption algorithms is called a CipherSuite, where the first part of the protocol is an agreement on selecting the correct set of CipherSuite from a list of preferred recommended CipherSuites. The reason for this initial phase is that some servers or clients may not support all ciphers, for technical or regulatory reasons.

How surprising…
It has been known for a long time that certain CipherSuites are bad. A good example was the Lucky13 attack from 2013, which basically showed an attack against any CipherSuite that used the MAC-then-Encrypt paradigm to protect the record layer. Another attack from 2013 showed that RC4 was also weak when used to encrypt the TLS record layer. As a cryptographer, I can say that to cryptographers such attacks were not surprising at all- both MAC-then-Encrypt and RC4 were known to be weak and were not being recommended for use in new systems years before 2013. Yet in 2013 we had real attacks and a lot of publicity, precisely because the CipherSuite negotiation for TLS for almost all secure connections on the internet resulted in one of these techniques being used to secure the record layer. Moving fast forward into 2015, this has now changed; web hosts and browser manufacturers are now making the preferred CipherSuites and are using a modern algorithm to secure the record layer such as AES-GCM.

But what did we eventually learn from this?
The lesson from 2013 was to not have CipherSuites which contained algorithms cryptographers recommend against using. However, TLS is so old (being based on the earlier SSL protocol) that it is not just the transport layer ciphers which can be considered old. In the early days of the internet, the US government tried to control the key sizes used outside the United States. This resulted in so-called export-strength (read weak) encryption algorithms. One of these was an export-strength variant of RSA. The FREAK attack exploits the fact that some servers will still respond to export strength CipherSuite requests. In particular a client can request a non-export strength RSA key, but then via a man-in-the-middle attack, the attacker gets the server to respond with an export strength key. This is a key which is so small that the RSA modulus can be factored.

So we in fact have the same problem: the server contains in its list of acceptable CipherSuites one which is considered insecure. The attack actually exploits a problem in the TLS state-machine in that the client does not reject when it receives an export strength key having asked for a strong key- but this is only exploitable due to servers still being configured with CipherSuites, which should have been removed well over a decade ago.

To FREAK out or not to FREAK out?
The real problem is with TLS configurations still allowing CipherSuites which are out of date, all in the name of flexibility. This flexibility leads to insecurity. The modern accepted way of running the TLS protocol is to choose a CipherSuite which has a forward-secure key agreement phase (one that does not use RSA encryption at all), followed by the use of a modern Authenticated Encryption algorithm for the transport layer. However, as can be seen from the FREAK attack, the internet is full of legacy software and systems which do not utilize modern cryptography.

Get a strong immune system
A research report on cryptographic protocols published recently by ENISA, and contributed by cryptographers- myself among them, outline recommendations as to the suitable CipherSuites to select in TLS.

Those organizations which only select CipherSuites from those recommended in the report are immune to all three attacks discussed in this article.

Prof. Nigel Smart

Prof. Nigel Smart

Nigel Smart, Unbound Co-Founder, is a Professor at University of Bristol UK. He is a world-renowned expert in applied cryptography, and was the Vice President of the International Association of Cryptologic Research. In the past, Nigel worked at Hewlett-Packard Laboratories developing advanced encryption technologies. He has also been involved in developing many standards, and has worked with both industry and government on applying cryptography to solve critical security problems.

Subscribe to BLOG

shares