CNS - 21 - TLS Handshake I
Lecture Info
Dates:
Lecturer: Giuseppe Bianchi
Slides:
Introduction: We will now begin the discussion of how the TLS Handshake Protocol, that is how the TLS protocol behaves in order to set up the connection.
1 TLS Handshake
An handshake happens the first time you initiate a connection towards an endpoint. During an handshake the following things are taken care of:
(mutual) authentication
agreeing on crypto algorithms
exchanging of random values
exchanging of secrets or info to compute secrets
Notice that even if TLS supports mutual authentication, it is typically used only to authenticate the server. Notice also that TLS supports multiple cryptographic algorithms, which means the specific algorithms used to secure the connection are choosen directly during the negotiation. This also means that an attacker could potentially hijack the negotiation phase, which means that we'll have to discuss techniques on how to secure such negotiations. These techniques will utilize public key cryptography.
It may happen that sometime after an initial TCP connection was made, the session gets suspendend and then a different TCP connection is initiated towards the same server. In this case there is another sort of handshake, an "abbreviated handshake" we could say, in which only secrets are refreshed. The key point is that each different connection uses unique keys. This is done as to limit the window of time in which we use the same crypto keys. Since public key crypto is much more expensive than symmetric crypto, these later abbreviated handshakes are done using information exchange during the first big handshake.
1.1 Goals
For an handshake to be correct, the following goals have to be satisfied:
Secure negotiation fo shared secrets via asymmetric crypto.
Optional authentication.
Reliable negotiation.
1.2 Messages sent
The messages sent during a TLS handshake can be visualized as follows
As we can see there are mainly four steps:
In the first part the client presents itself to the server.
Then the server presents itself to the client, proving who he is and so on.
Then the client proves who he is and sends some information related to the secrets.
Finally the server concludes the authentication.
Until TLS v1.2 all these \(4\) steps were necessary. Then in TLS v1.3 only \(3\) steps became necessary.
Notice that all these messages are sent using the basic TLS Record Layer structure, which we've already analyze. The only difference is that initially the messages are not encrypted, since both clients and server use the handshake to decide upon the crypto keys to use. The only encrypted messages are the last one the client and the server sends to eachothers.
Finally, all of these messages run over a TCP connection, and so its important to remember that TCP fragmentation
2 Example of TLS Trace
To understand better TLS it can be useful to analyze a trace. For example, consider the following packets which represent a TLS handshake
2.1 Client Hello
The first message in a TLS handshake is sent in plain text and it is incapsulated in a 5 bytes TLS record.
Within the Client Hello the following contents reside
Which are listed as follows:
The Handshake type, 1 byte.
The length, 3 bytes.
The version, 2 bytes.
A random value, 32 bytes.
(Session ID length, session ID), 1 + 32 bytes.
(Cipher suites lengths, Cipher suites), 1 + \(N \cdot 2\) bytes.
(Compression length, compression algorithm), 1 + 1 byte.
Some more specific about the content:
Notice that the client sends the TLS version two times: once in the record protocol, and once in the handshake protocol. The first version tells the server how the TLS packet is structured, while the second version is the client proposing to the server to use a specific version of TLS.
Before 4 bytes of the random value were given by the timestamp, but now all bytes are completely random.
The session ID is used tell if there is a session already avaiable or if a new one must be created.
Cipher suites have the following structure
the public key algorithm is used during the tls handshake, the symemtric algorithm is used to encrypt the tls packets after the handshake is done, and the hash algorithm is used to guarantee integrity with the HMAC. There are many cipher suites, such as
TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITh_NULL_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_EXPORT_WITh_RC2_CBC_40_MD5
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DS_anon_WITH_RC4_128_MD5
2.2 Server Hello
The server responds to the Client Hello with the following
as we can see, the server decided the session ID, the cipher suite and the compression method to be used for the later stages of the TLS session.
More precisely, the Server Hello contains the following:
Handshake type, 1 byte
Length, 3 bytes
Version,
Random value, 32 bytes
Session ID Length, session ID
Cipher suites, 2 bytes
Compression algo, 1 byte
More notes of interest:
The random value in the server reply is different from the one generated by the client.
If the client session ID is \(0\), then the server will generate a new session ID.
3 Asymmetric cryptography
The problem of asymmetric encryption is a classical problem that happens in many applications.
Consider for example all the tracing app that were developed to deal with the COVID-19 pandemic. All these apps allowed the users to simply download the app and then immediately transfer encrypted data to a central server. Now, how do you transfer and where do you store the symmetric key used to encrypt the communication? Putting it in the code is not a good idea, since by some good reverse engineering one can find ways to discovered it. This problem is solved by asymmetric cryptography.
Asymmetric cryptography is a cryptography scheme in which there are two keys: one used to encrypt the data and one used to decrypt the data.
The two requirements of asymmetric cryptography are the following:
The key used to encrypt and the one used to decrypt are different.
It should be impossible to determine the one starting from the other. This means that if you know the key used to encrypt, then in a computationally limited amount of time you should not able to determine the key used for decryption.
Asymmetric cryptography is also known as public/private cryptography, because asymmetric cryptography is widely used by exposing the encryption key and by keeping private the decryption key. We thus create this distinction
\[\begin{split} \text{public key} \,\,\, &\longleftrightarrow \,\,\, \text{encryption key} \\ \text{private key} \,\,\, &\longleftrightarrow \,\,\, \text{decryption key} \\ \end{split}\]
Consider the problem we have mentioned before: if each app wants to send some confidential data to the server, the app can simply encrypt the data with the public key of the server. In this case, even if the attacker sees the public key, only the server, that has the private key, is able to decrypt the data.
3.1 Asymmetric vs Symmetric
Notice that one shouldn't really compare asymmetric and symmetric cryptography and ask which is the better one. This is because:
They address different problems.
Both can be secure and insecure, depending on the algorithms and on the sizes of the keys.
Asymmetric is more flexible, but as a trade-off it requires more complex protocols.
Quantum computing affects many asymmetric encryption algorithms.
Asymmetric is computationally heavier than symmetric. In particular it is about 4-5 orders of magnitute slower.
The take-home message is that asymmetric encryption is only used to create a secure channel in which to send the symmetric key. Once the key has been exchanged, the bulk of the data is encrypted using the symmetric key.
4 Key Management in TLS
Up until TLS v1.2 the following two approaches were used for key management:
Key transport
Key agreement
4.1 Key Transport
This method works as follows
More in detail:
The server sends the public key to the client.
The client draws a random secret, which will be the key for symmetric encryption.
The key is encrypted with the public key of the server.
The encrypted key is transproted to the server.
At the end of the day the same secret key is on both sides.
4.2 Key Agreement
This other method does not make use of public key crypto, and it works as follows
More in detail:
Each parties generates indipendently a private and a public quantity.
They only exchange the public quantity.
By combining the public and the private quantity with modular exponentiation, they are able to construct the same secret.
This method is called the Diffie-Hellman Key Agreement, and its security relies on the fact that so far no one has been able to compute the discrete logarithm in polynomial time.
5 Handshake Phases
5.1 Phase 1
In the first phase the client and the server start to communicate
In particular the negotation works as follows: the client offers what he is able to support, and the server selects the best possible alternative for each of the following thing:
Agree on TLS/SSL version
Define session ID
Exchange nonces
Agree on cipher algorithms
Agree on compression algorithm
5.2 Phases 2 & 3 (Key Transport)
After the hello messages, the following messages happens when the keys are managed with a key transport
In particular,
Phase 2:
The server sends the authentication information (certificate).
Along with a public key.
Phase 3:
Client generates a shared secret
The public key of the server is used to encrypt the shared secret and to send it.
6 Downgrade Attack
A classical attack to negotiations is the so-called downgrade attack. In this attack the attacker downgrades the protocol version used to a more weaker and vulnerable version. This attack can also work on cipher suites.
Notice than that negotiation brings a sort of trade-off: one the one side you want to introduce the negotiation phase so as to have a modular protocol which is not bound to any specific crypto algorithms, but on the other side a negotiation phase opens up the possibility for a downgrade attack.
To solve this problem we need to use asymmetric cryptography. Indeed, to protect against this type of attack in the 2nd and third phase of the handshake, when the client is sending back to the server the shared key encrypted with the public key of the server, the client also adds the proper version of the protocol.
The point is that now the attacker cannot tamper with the certificate, and cannot modify the client reply. With this approach the server is able to realize if a downgrade attack is taking place.
Observation: Notice that this fix require asymmetric cryptography. Diffie-Hellman is not enough to protect against a downgrade attack, because with Diffie-Hellman we cannot transport data securely.
In more general terms, if in your protocol you want to make sure that what was said before the channel was secured is actually valid, you have to repeat after the channel is secured.