Incomplete Security

The TLS protocol (formerly SSL) is the basis of secure communications on the Internet. Every website that is accessed via HTTPS uses TLS in the background. However, TLS is getting on in years. Many design decisions were found to be unfavorable after extensive analyses, and the security of the protocol has been questioned. The reactions to these findings have been mostly patchwork. Small changes to the protocol have prevented attacks so far, but the problem is fundamental.

A Brief History of SSL

SSL (Secure Socket Layer) was originally developed by Netscape. In 1995, when the World Wide Web was still in its infancy, the former monopolist browser released the SSL encryption protocol version 2.0 (SSLv2). Version 1 existed only internally in Netscape. Numerous security vulnerabilities were discovered in SSLv2 after a short time.

SSLv2 supported many encryption algorithms that were already deemed insecure at the time, including the Data Encryption Standard (DES) in its original form with a key length of only 56 bits. The 1990s, when SSLv2 was being developed, were the hot phase of the "Crypto Wars." Strong encryption technologies were forbidden in the United States. Many states talked about only allowing strong encryption under state control – with a third key, which would be deposited with the secret service.

After that, Netscape published SSLv3 to fix at least the worst of the security problems. Although SSLv2 is only of historical importance today and has been disabled by virtually all modern browsers, its successor is still in use and you can still find web servers that only support SSLv3.

It was not until later that SSL was standardized. This process also involved renaming it to TLS (Transport Layer Security), which caused much confusion. In 1999, the IETF standardization organization published the TLS protocol version 1.0 in RFC 2246 (TLSv1.0). The now 14-year-old protocol is still the basis of the majority of encrypted communications. It later became known that the use of CBC encryption mode in TLSv1.0 was error-prone, but the problems long remained theoretical.

TLSv1.1, which was designed to iron out the worst weaknesses of CBC, followed in 2006. Two years later, TLSv1.2 was released, and it broke with some TLS traditions. TLSv1.1 and TLSv1.2 still exist in various niches. Support for the two protocols is still virtually non-existent many years later – and vulnerabilities that were once regarded as theoretical are now celebrating a comeback.

Block Ciphers, Stream Ciphers

Communicating over a TLS connection basically involves a hybrid solution between public key and symmetric encryption. Initially, the server and client negotiate a symmetric key via what is typically an RSA-secured connection. The key is then used for encrypted and authenticated communication.

Although the initial connection nearly always relies on an RSA key, the subsequent communication relies on a real zoo of algorithm combinations. Adding to the confusion is that naming does not follow a uniform pattern. One possible algorithm is, say, ECDHE-RSA-RC4-SHA. This means: an initial connection using RSA, then a key exchange using Diffie-Hellman with elliptic curves, then data encryption via RC4, and data authentication using SHA1.

A basic distinction is made in encryption between block ciphers and stream ciphers. A block cipher encrypts only a first block of a fixed length, for example 256 bits. A stream cipher can be applied directly to a data stream as it occurs in the data connection.

Block ciphers are the significantly more common approach. As a rule, the Advanced Encryption Standard (AES) is used today. This algorithm was published by the U.S. standards organization NIST after a competition between cryptographers in 2001.

Because a block cipher always encrypts a block of fixed length, it cannot be applied directly to a data stream. There are various modes, and in the simplest case, you just encrypt one block at a time. This Electronic Codebook Mode (ECB) cannot be recommended because of safety considerations.

How CBC and HMAC Work

The most popular and most common mode today is Cipher Block Chaining mode (CBC). First, the initialization vector (IV) is generated as a random value and bit-wise XORed with the first data block. The result is encrypted. The next block of data is then also XORed with the encrypted first block (the schema is shown in Figure 1).

Figure 1: The CBC schema is relatively simple.

However, encryption with CBC only warrants that the data cannot be read by an attacker. The authenticity of the data is not guaranteed. Therefore, the HMAC method is used in a TLS connection before encryption with CBC. A hash is formed from the message and the key and then transmitted.

The combination of HMAC and CBC proved to be surprisingly shaky. The decision first to use HMAC and then CBC especially turned out to be a mistake. The problem was that by introducing a defective data block based on the returned error message, an attacker can discover whether padding, which is filling up the missing bytes in a block, or the HMAC hash check causes an error. Earlier versions of TLS sent different error messages in these cases.

By sending a large number of faulty data blocks, an attacker could find out details about the key that was used. This form of attack was named "Padding Oracle." Later, the system was changed so that an attacker always received the same error message. But along came the next problem: The response time still allowed the attacker to find out whether verification failed in the data block during padding or in the HMAC hash.

These methods are the basis for recently disclosed attacks like BEAST [1] and Lucky Thirteen [2]. Detailed changes in the protocol implementations prevented these attacks in the short turn, but that turned out to be anything but simple. It was shown, for example, that one of the changes introduced to prevent the BEAST attack just enabled a form of the Lucky Thirteen attack.