cnp3-ebook/protocols/tls — French @ Weblate: Footnotes

	English	French	Actions
	In 2014, the IETF TLS working started to work on the development of version 1.3 of the TLS protocol. Their main objectives [Rescorla2015]_ for this new version were:
	simplify the design by removing unused or unsafe protocol features
	improve the security of TLS by leveraging the lessons learned from TLS 1.2 and some documented attacks
	improve the privacy of the protocol
	reduce the latency of TLS
	Since 2014, latency has become an important concern for web services. As access networks bandwidth continue to grow, latency is becoming a key factor that affects the performance of interactive web services. With TLS 1.2, the download of a web page requires a minimum of four round-trip-times, one to create the underlying TCP connection, one to exchange the ClientHello/ServerHello, one to exchange the keys and then one to send the HTTP GET and retrieve the response. This can be very long when the server is not near the client. TLS 1.3 aimed at reducing this handshake to one round-trip-time and even zero by placing some of the cryptographic handshake in the TCP handshake. This part will be discussed in the TCP chapter. We focus here on the reducing the TLS handshake to a single round-trip-time.
	To simplify both the design and the implementations, TLS 1.3 uses only a small number of cipher suites. Five of them are specified in :rfc:`8446` and ``TLS_AES_128_GCM_SHA256`` must be supported by all implementations. To ensure privacy, all cipher suites that did not provide Perfect Forward Secrecy have been removed. Compression has also been removed from TLS since several attacks on TLS 1.2 exploited its compression capability :rfc:`7457`.
	Enterprises, privacy and TLS
	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]_.
	The TLS 1.3 handshake differs from the TLS 1.2 handshake in several ways. First, the TLS 1.3 handshake requires a single round-trip-time when the client connects for the first time to a server. To achieve this, the TLS designers look at the TLS 1.2 handshake in details and found that the first round-trip-time is mainly used to select the set of cryptographic algorithms and the cryptographic exchange scheme that will be used over the TLS session. TLS 1.3 drastically simplifies this negotiation by requiring to use the Diffie Hellman exchange with a small set of possible parameters. This means that the client can guess the parameters used by the server (i.e. the modulus, p and the base g) and immediately start the Diffie Hellman exchange. A simplified version of the TLS 1.3 handshake is shown in the figure below.
	There are several important differences with the TLS 1.2 handshake. First, the Diffie Hellman key exchange is required in TLS 1.3 and this exchange is initiated by the client (before having validated the server identity). To initiate the Diffie Hellman key exchange, the client needs to guess the modulus and the base that can be accepted by the server. Either the client uses standard parameters that most server supports or the client remembers the last modulus/base that it used with this particular server. If the client guessed incorrectly, the server replies with the parameters that it expects and one round-trip-time is lost. When the server sends its `ServerHello`, it already knows the session key. This implies that the server can encrypt all subsequent messages. After one round-trip-time, all data exchanged over the TLS 1.3 session is encrypted and authenticated. In TLS 1.3, the server certificate is encrypted with the session key, as well as the `Finished` message. The server signs the handshake to confirm that it owns the public key of its certificate. If the server wants to send application data, it can already encrypt it and send it to the client. Upon reception of the server Certificate, the client verifies it and checks the signature of the handshake and the `Finished` message. The client confirms the end of the handshake by sending its own `Finished` message. At that time, the client can send encrypted data. This means that the client only had to wait one round-trip-time before sending encrypted data. This is much faster than with TLS 1.2.
	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.
	On the web, TLS clients use certificates to authenticate servers but the clients are not authenticated. However, there are environments such as enterprise networks where servers may need to authenticate clients as well. A popular deployment is to authenticate remote clients who wish to access the enterprise network through a Virtual Private Network service. Some of these services run above TLS (or more precisely a variant of TLS named DTLS that runs above UDP [MoR2004]_ but is outside the scope of this chapter). In such services, each client is authenticated thanks to a public key and a certificate that is trusted by the servers. To establish a TLS session, such a client needs to prove that it owns the public key associated with the certificate. This is done by the server thanks to the CertificateRequest message. The TLS handshake becomes the following one:
	The server sends a CertificatRequest message. The client returns its certificate and signs the Handshake with is private key. This confirms to the server that the client owns the public key indicated in its certificate.
	There are many more differences between TLS 1.2 and TLS 1.3. Additional details may be found in their respective specifications, :rfc:`5246` and :rfc:`8446`.
	Footnotes
	See http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
	A detailed explanation of the TLS 1.3 handshake may be found at https://tls13.ulfheim.net/
	See https://letsencrypt.org/stats/ for a graph and https://docs.telemetry.mozilla.org/datasets/other/ssl/reference.html for additional information on the dataset

	Component	Translation	Difference to current string
	This translation Propagated Empty cnp3-ebook/protocols/tls
The following strings have the same context and source.
	Propagated Translated cnp3-ebook/exercises/transport	Notes de pied de page	Notes de pied de page
	Propagated Translated cnp3-ebook/principles/naming	Notes de pied de page	Notes de pied de page
	Propagated Translated cnp3-ebook/principles/referencemodels	Notes de pied de page	Notes de pied de page
	Propagated Translated cnp3-ebook/principles/security	Notes de pied de page	Notes de pied de page
	Propagated Translated cnp3-ebook/exercises/dns	Notes de pied de page	Notes de pied de page
	Propagated Translated cnp3-ebook/exercises/http	Notes de pied de page	Notes de pied de page
	Propagated Translated cnp3-ebook/exercises/tcp	Notes de pied de page	Notes de pied de page
	Propagated Translated cnp3-ebook/exercises/tls	Notes de pied de page	Notes de pied de page
	Propagated Empty cnp3-ebook/protocols/bgp
	Propagated Empty cnp3-ebook/protocols/dnssec
	Propagated Empty cnp3-ebook/protocols/http2
	Propagated Empty cnp3-ebook/protocols/ppp
	Propagated Empty cnp3-ebook/protocols/rpc
	Propagated Empty cnp3-ebook/protocols/ipv6
	Propagated Translated cnp3-ebook/principles/sharing	Notes de pied de page	Notes de pied de page
	Propagated Empty cnp3-ebook/protocols/udp
	Propagated Empty cnp3-ebook/protocols/wifi
	Propagated Translated cnp3-ebook/exercises/sockets	Notes de pied de page	Notes de pied de page
	Propagated Translated cnp3-ebook/principles/network	Notes de pied de page	Notes de pied de page

None

New source string

cnp3-ebook / protocols/tls — French

New source string 3 years ago

Browse all component changes

cnp3-ebook

protocols/tls

French

Translate

Translation

Things to check

Inconsistent

Glossary

String information

Source string location

String age

Source string age

Translation file