CNS - 17 - TLS II
Lecture Info
Date:
Lecturer: Giuseppe Bianchi
Slides:
Introduction:
1 TLS Record Protocol
As we saw in the last lecture, TLS runs between the application and the transport layer (typically TLS). To construct a TLS record protocol the following operations are executed
Let us now discuss in more detail each layer.
1.1 Fragmentation
The idea is take in the application data and to chop it into pieces which have a size of \(2^{14} = 16384\) bytes.
Do not confuse fragmentation at this level with TCP fragmentation, which comes later on the processinng pipeline.
1.2 Compression
Since typically application data is very verbose and low entropy, the idea was to compress the data in order to make the transfer more efficient.
Notice that if we choose to compress the data we have to do it before encryption, because after encryption the entropy of the data should be maximized. It thus does not make sense to encrypt and then compress.
The compression layer was introduced in SSLv2, in 1995. It was then considered in TLS v1.0 but was not specified, meaning that there was no compression algorithm specified. In 2004 they ported the compression mechanism DEFLATE. After compression became widely used, it suddenly died in september 2012 after the discovery of the CRIME attack, which enable attackers to use the combination of encryption + compression to decrypt the data.
1.3 MAC Computation
At the time of TLS v1.0 there was no AEAD algorithm that could offer confidentiality and integrity of the data. In the protocol thus integrity and confidentiality are handled in two separate levels.
As far as the integrity went, an HMAC was used. The HMAC uses:
A secret, symmetric key derived from security parameters neogiated during handshake.
An hash function neogiated during handshake.
The particular HMAC construction used was keyed-hashing Message Authentication (RFC 2104).
1.4 Encryption
The encrypted message is both the compressed data as well as the MAC data. To encrypt the data either block ciphers or stream cipher can be used.
The particular encryption algorithm, as well as the secret key used, are both negotiated during the handshake phase. Algorithms can be choosen also among the following:
RC4
3DES
AES
Notice that an encryptin algorithm may increase the size of the plaintext, but this increase cannot be more than 1024 bytes.
1.5 Record Protocol Data Unit
After all of this a header is added on top of the packet to construct the final record protocol data unit. The data unit is visualized as follows
Where,
The Content-Type can either be:
Application data
Alert
Handshake
Change_cipher_spec
1.5.1 What about replay?
Notice that so far we have not explicitly put any kind of nonce in our TLS packets. This means that potentially TLS could be vulnerable to replay attacks.
This however is not the case, because TLS implicitly uses as nonce the sequence numbers used by the TCP connection. Since TCP is a reliable transport, there will be no "holes" in the communication, and the order in which one end-point sends the packets to the other end-point will be reconstructed once again in the other end-point. So there is no need to include the explicit sequence number in the TLS packet.
To actually perfom message authentication of the final tls packet then during the computation of the HMAC you also need to include the sequence number taken from the TCP packet
This is the reason why until the definition of DTLS the TLS protocol could only work with TCP: in DTLS the nonce has to be explicitly included, while in TLS it is only implicitly included using TCP sequence numbers.
2 Encryption and Authentication
In general encryption and authentication are two different security service. The only mechanisms which guarantees both services are called AEAD ciphersuites, where AEAD stands for Authentication Encryption with Associated Data, which were specified in RFC 5116.
To combine encryption and authentication typically three different approaches are used:
TLS: first do the MAC and only then ENCRYPT the data. In this case the MAC is computed over the plaintext.
IPsec: First ENCRYPT then MAC. In this case the MAC is computed over the encrypted data.
ssh: Compute the MAC of the plaintext data, and ENCRYPT only the data.
Do these constructions differ in any meaningful way? And if so, what is the best construction, assuming that we're using a general (semantically secure) ENCRYPTION scheme as well as a general (unforgeable) MAC scheme? In this case for "best construction" we mean the construction that preserves the original security properties we want to have.
Notice that the solution adopted by ssh breaks semantic security, since by using the MAC an attacker can recognize whether two messages encrypt the same underlying data.
The correct way to actually combine encryption and integrity is actually the second way, the one used by IPsec.
Observation: Krawcyzk constructed a pathological counterexample which showed how it was possible to break a system obtained by combining encryption and integrity following the TLS way. The counterxample however was so artificial that it was not convincing enough. Then more practical attacks (although not on TLS) on this particular combination order were discovered, and finally starting from 2002 until 2016 a series of padding oracle attacks broke this combination.
So, if you ever need to choose how to combine encryption and integrity, you should always first ENCRYPT and then MAC.
3 Block Ciphers
The difference between a block cipher and a stream cipher is the operation that is used to encrypt the data. As we have seen in one of the first lecture, a stream cipher works by XORing the data with a keystream obtained by a secure PRNG.
In a block cipher you take the data and you chop into blocks of a given size. You then apply to each block a "secure" pseudo random permutation, which is a reversible transformation that transforms a block into a cipher text.
Notice however that like this we lose semantic security, since each plain-text block is deterministically mapped into an encrypted block. This means that defining the block transformation is not enough. What we also need is to have a secure way to combine the block transformations to encrypt a text of arbitary length in order to make it semantically secure.
3.1 PRP to Cipher
There are various ways in which we can combine the block transformations. Some of these are not secure, and some of these are secure. We will now mention some of them:
Eletronic Code Book (ECB): This works by basically doing nothing. This obviously completely loses semantic security, and should thus not be used.
Cipher Block Chain (CBC): The idea is to scramble each block with some extra data. To do this an IV (initialization vector) is randomly generated, and is then used to scramble the first message. The resulting ciphertext is used then to scramble the second block, and so on until all blocks are scrambled. This scheme turns out to be semantically secure on most conditions.
