English
110
119
143
21
443
563
80
990
993
995
A detailed explanation of the TLS 1.3 handshake may be found at https://tls13.ulfheim.net/
a `Length` field. A TLS record cannot be longer than 16,384 bytes.
All the information required for the key exchange has now been transmitted. There are two important messages that will be sent by the client and the server to conclude the handshake and start the data transfer phase.
An important difference between ``DHE_RSA`` and ``RSA`` is their reaction against attacks. ``DHE_RSA`` is considered by many to be stronger than ``RSA`` because it supports `Perfect Forward Secrecy`. This property is important against attackers that are able to eavesdrop all the (encrypted) data sent and received by a server. Consider that Terrence is such an attacker that has stored all the packets exchanged by Bob's server during the last six months. If he manages, by any means, to obtain Bob's private key, he will be able to decrypt all the keys used to secure the TLS sessions with Bob's server during this period. With ``DHE_RSA``, a similar attack is less devastating. If Terrence knows Bob's private key, he will be able to launch a man-in-the-middle attack against future TLS sessions with Bob's server. However, he will not be able to recover the keys used for all the past sessions that he captured.
Another interesting fact is are the key exchange schemes. In 2012, RSA was the dominant solution, used by more than 80% of the observed connections [KRA2018]_. In 2013, Edward Snowden revealed the surveillance activities of several governments. These revelations had a huge impact on the Internet community. The IETF, which standardizes Internet protocols, considered in :rfc:`7258` that such pervasive monitoring was an attack. Since then, several IETF working groups have developed solutions to counter pervasive monitoring. One of these solutions is to encourage `Perfect Forward Security`. Within TLS, this implies replacing RSA by an authenticated Diffie Hellman key exchange such as ECDHE. Measurements indicate that since summer 2014, ECDHE is more popular than RSA. In 2018, more than 90% of the observed TLS connections used ECDHE.
Application
a `Protocol Version` field that indicates the version of the TLS protocol used. This version is composed of two sub fields : a major and a minor version number.
A second approach to initiate a TLS session is to use the standard TCP port number for the application layer protocol and define a special message in this protocol to trigger the start of the TLS session. This is the solution used for SMTP with the ``STARTTLS`` message. This extension to SMTP :rfc:`3207` defines the new STARTTLS command. The client can issue this command to indicate to the server that it wants to start a TLS session as shown in the example below captured during a session on port 25.
As other security protocols, TLS uses different keys to encrypt and authenticate records. These keys are derived from the MasterSecret that is either randomly generated by the client after the ``RSA`` key exchange or derived from the Diffie Hellman parameters after the ``DH_RSA`` key exchange. The exact algorithm used to derive the keys is defined in :rfc:`5246`.
A TLS cipher suite is usually represented as an ASCII string that starts with TLS and contains the acronym of the key exchange algorithm, the encryption scheme with the key size and its mode of operation and the authentication algorithm. For example, ``TLS_DHE_RSA_WITH_AES_128_GCM_SHA256`` is a TLS cipher suite that uses the ``DHE_RSA`` key exchange algorithm with 128 bits AES in GCM mode for encryption and SHA-256 for authentication. The official list of TLS cipher suites is maintained by IANA [#fianaTLS]_. The NULL acronym indicates that no algorithm has been specified. For example, ``TLS_ECDH_RSA_WITH_NULL_SHA`` is a cipher suite that does not use any encryption but still uses the ``ECDH_RSA`` key exchange and ``SHA`` for authentication.