cnp3-ebook/protocols/tls — English @ Weblate

Exit Zen

76 ../../protocols/tls.rst:403

	English simplify the design by removing unused or unsafe protocol features 66/10000 · 66
77 ../../protocols/tls.rst:404

	English improve the security of TLS by leveraging the lessons learned from TLS 1.2 and some documented attacks 102/10000 · 102
78 ../../protocols/tls.rst:405

	English improve the privacy of the protocol 35/10000 · 35
79 ../../protocols/tls.rst:406

	English reduce the latency of TLS 25/10000 · 25
80 ../../protocols/tls.rst:408

	English 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. 803/10000 · 803
81 ../../protocols/tls.rst:410

	English 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`. 445/10000 · 445
82 ../../protocols/tls.rst:413

	English Enterprises, privacy and TLS 28/10000 · 28
83 ../../protocols/tls.rst:415

	English 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]_. 768/10000 · 768
84 ../../protocols/tls.rst:417

	English 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. 821/10000 · 821
85 ../../protocols/tls.rst:447

	English 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. 1574/10000 · 1574
86 ../../protocols/tls.rst:454

	English 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. 1066/10000 · 1066
87 ../../protocols/tls.rst:482

	English 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: 869/10000 · 869
88 ../../protocols/tls.rst:510

	English 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. 219/10000 · 219
89 ../../protocols/tls.rst:512

	English 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`. 157/10000 · 157
90 ../../protocols/tls.rst:515

	English Footnotes 9/10000 · 9
91 ../../protocols/tls.rst:516

	English See http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 88/10000 · 88
92 ../../protocols/tls.rst:518

	English A detailed explanation of the TLS 1.3 handshake may be found at https://tls13.ulfheim.net/ 90/10000 · 90
93 ../../protocols/tls.rst:519

	English 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 161/10000 · 161
The translation has come to an end.

Shortcut	Action
`?`	Open available keyboard shortcuts.
`Alt` + `Home`	Navigate to the first translation in the current search.
`Alt` + `End`	Navigate to the last translation in the current search.
`Alt` + `PageUp` or `Ctrl` + `↑` or `Alt` + `↑` or `Cmd` + `↑` or	Navigate to the previous translation in the current search.
`Alt` + `PageDown` or `Ctrl` + `↓` or `Alt` + `↓` or `Cmd` + `↓` or	Navigate to the next translation in the current search.
`Ctrl` + `Enter` or `Cmd` + `Enter`	Submit current form; this works the same as pressing Save and continue while editing translation.
`Ctrl` + `Shift` + `Enter` or `Cmd` + `Shift` +`Enter`	Unmark translation as Needing edit and submit it.
`Alt` + `Enter` or `Option` + `Enter`	Submit the string as a suggestion; this works the same as pressing Suggest while editing translation.
`Ctrl` + `E` or `Cmd` + `E`	Focus on translation editor.
`Ctrl` + `U` or `Cmd` + `U`	Focus on comment editor.
`Ctrl` + `M` or `Cmd` + `M`	Shows Automatic suggestions tab.
`Ctrl` + `1` to `Ctrl` + `9` or `Cmd` + `1` to `Cmd` + `9`	Copies placeable of a given number from source string.
`Ctrl` + `M` followed by `1` to `9` or `Cmd` + `M` followed by `1` to `9`	Copy the machine translation of a given number to current translation.
`Ctrl` + `I` followed by `1` to `9` or `Cmd` + `I` followed by `1` to `9`	Ignore one item in the list of failing checks.
`Ctrl` + `J` or `Cmd` + `J`	Shows the Nearby strings tab.
`Ctrl` + `S` or `Cmd` + `S`	Focus on search field.
`Ctrl` + `O` or `Cmd` + `O`	Copy the source string.
`Ctrl` + `Y` or `Cmd` + `Y`	Toggle the Needs editing checkbox.
`→`	Browse the next translation string.
`←`	Browse the previous translation string.