Authentication and Encryption

More modern block encryption modes combine authentication and encryption in a single step. One of these modes is called the Galois/Counter Mode (GCM, Figure 2). Although this mode is considered relatively complicated, GCM is free of patent claims, in contrast to other methods, and has no known security problems.

Figure 2: Authentication and encryption in one – Galois/Counter Mode.

The AES-GCM process is supported in version 1.2 of TLS. In all previous versions of TLS, all block ciphers rely on CBC. The authors of the BEAST attack published yet another attack on TLS. The CRIME attack [3] also targets a timing issue. Here, the authors take advantage of a weakness in the TLS compression routine. Based on the response time of a server, they can draw conclusions as to the contents of a data block.

TLS data compression is rarely used because many browsers do not support it. For server administrators, it is best simply to disable it.

In addition to TLS block ciphers, older versions also support RC4 stream encryption. The method was developed by Ron Rivest and was not originally intended for publication. But, in 1994, the RC4 encryption source code appeared in a newsgroup. Since then, it has become very popular because it is relatively simple and very fast.

The use of RC4 is also possible in TLS and is actually the only option in older versions of the standard if you want to avoid the use of CBC. Therefore, many experts until recently recommended setting up TLS connections exclusively on RC4. Large websites such as Google rely on RC4 as the primary algorithm, and the credit card standard PCI DSS required server administrators to disable all CBC algorithms and to accept only connections via RC4. This was a mistake, as it turned out. At the Fast Software Encryption Workshop in March, a team led by cryptographer Dan Bernstein presented an attack on RC4 and TLS [4].

In RC4 stream encryption, certain bits in some places do not appear randomly, but with increased frequency. Statistical analysis thus lets attackers draw conclusions about the content. A potential target could be, say, a cookie in a web application.

Unlike the vulnerabilities in CBC, there is probably no easy way to fix the problems in RC4 in the scope of TLS without breaking the standard. The recommendation to use RC4 instead of CBC is no longer an option.

Perfect Forward Secrecy

One possibility that some TLS algorithms offer is a key exchange. This approach ensures that the real key for data transmission is never transmitted across the wire. After the data transmission, the temporary key is destroyed. The big advantage here is that even if an attacker hijacks the connection and later gains possession of the private key, he cannot decrypt the content. This property is called Perfect Forward Secrecy. It is generally desirable, and the most common method for this is a Diffie-Hellman key exchange.

TLS supports this, but, annoyingly, the Apache web server does not let you define the parameter length for the key exchange. A standard length of 1024 bits is specified but is not enough. In processes such as Diffie-Hellman, which are based on the discrete logarithm problem, key lengths of 1024 bits should be avoided and at least 2048 bits should be used. Alternatively, TLS provides a key exchange with elliptic curve Diffie-Hellman. This method is considered secure even with much shorter key lengths.

In the Face of Vulnerabilities

It should be emphasized that the probability that the attacks discussed so far will lead to problems in real-world applications is quite low. However, the authors of the Lucky Thirteen attack explicitly say they expect further surprises with CBC. Even the authors of the attack on RC4 assume that improved attack methods will soon exist.

In the long term, it is thus desirable to completely banish CBC. This tactic also dramatically reduces the zoo of encryption modes that TLS supports. In TLSv1.1 and all earlier versions, all block cipher methods use CBC. All processes using 3DES, IDEA, or CAMELLIA thus drop away. For reasons of backward compatibility, it is now typically impossible to rely on TLSv1.2 alone (Figure 3), which leaves only the problematic RC4 stream cipher.

Figure 3: Google.de via HTTPS – the connection uses RC4 with TLSv1.1; Chrome does not support TLSv1.2.

In TLSv1.2, only AES encryption is supported in both (the problematic) CBC mode and the more modern GCM mode (Galois/Counter Mode). Both are also offered with and without Perfect Forward Secrecy.

In the best case, you would want to disable everything except the GCM algorithms; however, this approach only works for applications in which you have control over all clients and know that they support TLSv1.2. The pragmatic compromise was to continue to rely provisionally on CBC-based methods and ensure that only the current version of the SSL library  – in most cases OpenSSL – is used, with all security updates in place.