2. cnp3-ebook
3. protocols/tls
4. English
5. Zen

37 ../../protocols/tls.rst:155
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `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`. 488/10000 · 488
38 ../../protocols/tls.rst:162
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `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`. 387/10000 · 387
39 ../../protocols/tls.rst:167
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `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. 208/10000 · 208
40 ../../protocols/tls.rst:173
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``Server Name Indication (SNI)`` 36/10000 · 36
41 ../../protocols/tls.rst:175
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``Server Name Indication (SNI)`` extension defined in :rfc:`6066` is an important TLS extension for web servers. It is used by the client to indicate the name of the server that it wishes to contact. The IP address associated to this name has been queried from the DNS and used to establish the TCP connection. Why should the client indicate the server name in the TLS ``ClientHello`` ? The motivation is the same as for the ``Host`` header line in HTTP/1.0. With the SNI extension, a single TLS server can support several web sites that use different domain names. Thanks to the SNI extension, the server knows the concerned domain name at the start of the TLS session. Without this extension, hosting providers would have been forced use one IP address per TLS-enabled server. 783/10000 · 783
42 ../../protocols/tls.rst:190
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The server replies to the ``ClientHello`` with several messages: 64/10000 · 64
43 ../../protocols/tls.rst:192
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the ``ServerHello`` message that contains the protocol version chosen by the server (assumed to be the same as the client version in this chapter), the 32 random bytes chosen by the server, the `Cipher Suite` selected by the server from the list advertised by the client and a `Session Id`. This `Session Id` is an identifier which is chosen by the server. It identifies the TLS session and the security parameters (algorithms and keys) negotiated for this session. It is used to support session resumption. 507/10000 · 507
44 ../../protocols/tls.rst:200
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the ``Certificate`` message provides the certificate (or usually a chain of certificates) that binds a domain name to the public key used by the server. TLS uses the server certificates to authenticate the server. It relies on a Public Key Infrastructure that is composed of a set of root certification authorities that issue certificates to certification authorities that in the end issue certificates to servers. TLS clients are usually configured with the public keys of several root certification authorities and use this information to validate the certificates that they receive from servers. For historical reasons, the TLS certificates are encoded in ASN.1 format. The details of the ASN.1 syntax [Dubuisson2000]_ are outside the scope of this book. 757/10000 · 757
45 ../../protocols/tls.rst:212
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the ``ServerKeyExchange`` message is used by the server to transmit the information that is required to perform the key exchange. The content of this message is function of the selected key exchange algorithm. 209/10000 · 209
46 ../../protocols/tls.rst:215
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the ``ServerHelloDone`` indicates that the server has sent all the messages for the first phase of the handshake. 113/10000 · 113
47 ../../protocols/tls.rst:220
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 231/10000 · 231
48 ../../protocols/tls.rst:225
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``RSA``. This key exchange algorithm uses the encryption capabilities of the RSA public-key algorithm. The client has validated the server's public key thanks to the ``Certificate`` message. It then generates a (48 bytes) random number, encrypts it with the server public key and sends the encrypted number to the server in the ``ClientKeyExchange`` message. The server uses its private key to decrypt the random number. At this point, the client and the server share the same (48 bytes long) secret and use it to derive the secret keys required to encrypt and authenticate data in the second phase. With this key exchange algorithm, the server does not need to send a ``ServerKeyExchange`` message. 699/10000 · 699
49 ../../protocols/tls.rst:236
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``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). 722/10000 · 722
50 ../../protocols/tls.rst:250
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 915/10000 · 915
51 ../../protocols/tls.rst:266
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Perfect Forward Secrecy 23/10000 · 23
52 ../../protocols/tls.rst:268
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Perfect Forward Secrecy (PFS) is an important property for key exchange protocols. A protocol provides PFS if its design guarantees that the keys used for former sessions will not be compromised even if the private key of the server is compromised. This is a very important property. ``DHE_RSA`` provides Perfect Forward Secrecy, but the ``RSA`` key exchange does not provide this property. In practice, ``DHE_RSA`` is costly from a computational viewpoint. Recent implementations of TLS thus prefer ``ECDHE_RSA`` or ``ECDHE_ECDSA`` when Perfect Forward Secrecy is required. 575/10000 · 575
53 ../../protocols/tls.rst:279
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 216/10000 · 216
54 ../../protocols/tls.rst:283
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The client sends the ``ChangeCipherSpec`` message followed by the ``Finished`` message. The ``ChangeCipherSpec`` message indicates that the client has received all the information required to generate the security keys for this TLS session. This messages can also appear later in the session to indicate a change in the encryption algorithms that are used, but this usage is outside the scope of this book. The ``Finished`` message is more important. It confirms to the server that the TLS handshake has been performed correctly and that no attacker has been able to modify the data sent by the client or the server. This is the first message that is encrypted with the selected security keys. It contains a hash of all the messages that were exchanged during the handshake. 774/10000 · 774
55 ../../protocols/tls.rst:294
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The server also sends a ``ChangeCipherSpec`` message followed by a ``Finished`` message. 88/10000 · 88
56 ../../protocols/tls.rst:297
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TLS Cipher suites 17/10000 · 17