2. cnp3-ebook
3. protocols/tls
4. French
5. Browse

2 / 5

/ 5

All strings

• Untranslated strings • state:empty
• Unfinished strings • state:<translated
• Translated strings • state:>=translated
• Strings marked for edit • state:needs-editing
• Strings with suggestions • has:suggestion
• Strings with variants • has:variant
• Strings with labels • has:label
• Strings with context • has:context
• Unfinished strings without suggestions • state:<translated AND NOT has:suggestion
• Strings with comments • has:comment
• Strings with any failing checks • has:check
• Approved strings • state:approved
• Strings waiting for review • state:translated

Source string

• Position and priority
• Position
• Priority
• Labels
• Source string
• Target string
• String age
• Number of words
• Number of comments
• Number of failing checks
• Key

	English	French
	a `TLSPlainText` that contains the encrypted data
	A TLS record is always composed of four different fields :
	A TLS session can be initiated in two different ways. First, the application can use a dedicated TCP port number for application layer protocol x-over-TLS. This is the solution used by many HTTP servers that reserve port :math:`443` for HTTP over TLS. This solution works, but it requires to reserve two ports for each application : one where the application-layer protocol is used directly over TCP and another one where the application-layer protocol is used over TLS. Given the limited number of TCP ports that are available, this is not a scalable solution. The table below provides some of the reserved port numbers for application layer protocols on top of TLS.
	A TLS session is divided in two phases: the handshake and the data transfer. During the handshake, the client and the server negotiate the security parameters and the keys that will be used to secure the data transfer. During the second phase, all the messages exchanged are encrypted and authenticated with the negotiated algorithms and keys.
	A TLS session operates over a TCP connection. TLS is responsible for the encryption and the authentication of the SDUs exchanged by the application layer protocol while TCP provides the reliable delivery of this encrypted and authenticated bytestream. TLS is used by many different application layer protocols. The most frequent ones are HTTP (HTTP over TLS is called HTTPS), SMTP :rfc:`3207` or POP and IMAP :rfc:`2595`, but proprietary application-layer protocols also use TLS [AM2019]_.
	At this point, it is time to describe the TLS key exchange. TLS supports different key exchange mechanisms that can be negotiated as part of the selection of the cipher suite. We focus on two of them to highlight their differences:
	a `Type` that indicates the type of record. The most frequent type is `application data` which corresponds to a record containing encrypted data. The other types are `handshake`, `change_cipher_spec` and `alert`.
	By supporting only cipher suites that provide Perfect Forward Secrecy in TLS 1.3, the IETF aims at protecting the privacy of users against a wide range of attacks. However, this choice has resulted in intense debates in some enterprises. Some enterprises, notably in financial organizations, have deployed TLS, but wish to be able to decrypt TLS traffic for various security-related activities. These enterprises tried to lobby within the IETF to maintain RSA-based cipher suites that do not provide Perfect Forward Secrecy. Their arguments did not convince the IETF. Eventually, these enterprises moved to ETSI, another standardization body, and convinced them to adopt `entreprise TLS`, a variant of TLS 1.3 that does not provide Perfect Forward Secrecy [eTLS2018]_.
	`Cipher suites` : this ordered list contains the set of cryptographic algorithms that are supported by the client, with the most preferred one listed first. In contrast with ``ssh`` that allows negotiating independent algorithms for encryption, key exchange and authentication, TLS relies on suites that combine these algorithms together. Many cryptographic suites have been defined for TLS. Various recommendations have been published on the security of some of these suites :rfc:`7525`.
	`Compression algorithm` : the client may propose the utilization of a specific compression algorithm (e.g. zlib). In theory, compressing the data before encrypting it is an intelligent way to reduce the amount of data exchanged. Unfortunately, its implementation in TLS has caused several security problems [PHG2013]_. For this reason, compression is usually disabled in TLS :rfc:`7525`.
	``DHE_RSA``. This key exchange algorithm is the Ephemeral Diffie Hellman key exchange with RSA signatures to authenticate the key exchange. It operates as a classical authenticated Diffie Hellman key exchange. If this key exchange has been selected by the server, it sends its Diffie Hellman parameters in the ``ServerKeyExchange`` message and signs them with its private key. The client then continues the key exchange and sends the results of its own computation in the ``ClientKeyExchange`` message. ``DHE_RSA`` is thus an authenticated Diffie Hellman key exchange where the initial message is sent by the server (instead of the client as in our first example but since the protocol is symmetric, this does not matter).
	During the last two decades, the deployment of TLS has continued to grow. The early TLS servers were only used for critical services such as e-commerce websites or online banks. As CPU performance improved, it became much more cost-effective to use TLS to secure non-critical parts of web servers, including the delivery of HTML pages and even video services. There is now a growing number of applications that rely on TLS [AM2019]_.
	Enterprises, privacy and TLS
	`Extensions` : TLS supports various extensions in the ``ClientHello`` message. These extensions :rfc:`6066` are important to allow the protocol to evolve, but many of them go beyond the scope of this chapter.
	Footnotes
	For some applications, waiting one round-trip-time before being able to send data is too long. TLS 1.3 allows the client to send encrypted data immediately after the `ClientHello`, without having to wait for the `ServerHello` message. At this point in the handshake, the client cannot know the key that will be derived by the Diffie Hellman key exchange. The trick is that the server and the client need to have previously agreed on a `pre-shared-key`. This key could be negotiated out of band, but usually it was exchanged over a previous TLS session between the client and the server. Both the client and the server can store this key in their cache. When the client creates a new TLS session to a server, it checks whether it already knows a pre-shared key for this server. If so, the client announces the identifier of this key in its `ClientHello` message. Thanks to this identifier, the server can recover the key and use it to decrypt the 0-rtt Encrypted record. A simplified version of the 0-rtt TLS 1.3 handshake [#fhandshake]_ is shown in the figure below.
	FTP
	HTTP
	IMAP
	improve the privacy of the protocol