Exit Zen
15
../../protocols/tls.rst:45
English
NNTP
0/100 · 4
16
../../protocols/tls.rst:45
English
119
0/100 · 3
17
../../protocols/tls.rst:45
English
563
0/100 · 3
18
../../protocols/tls.rst:46
English
HTTP
0/100 · 4
19
../../protocols/tls.rst:46
English
80
0/100 · 2
20
../../protocols/tls.rst:46
English
443
0/100 · 3
21
../../protocols/tls.rst:47
English
FTP
0/100 · 3
22
../../protocols/tls.rst:47
English
21
0/100 · 2
23
../../protocols/tls.rst:47
English
990
0/100 · 3
24
../../protocols/tls.rst:51
English
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.
0/5040 · 504
25
../../protocols/tls.rst:77
English
In the remaining parts of this chapter, we assume that the TLS session starts immediately after the establishment of the TCP connection. This corresponds to the deployments on web servers. We focus our presentation of TLS on this very popular use case. TLS is a complex protocol that supports other features than the one used by web servers. A more detailed presentation of TLS may be found in [KPS2002]_ and [Ristic2015]_.
0/4230 · 423
26
../../protocols/tls.rst:84
English
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.
0/3430 · 343
27
../../protocols/tls.rst:93
English
The TLS handshake
0/170 · 17
28
../../protocols/tls.rst:95
English
When used to interact with a regular web server, the TLS handshake has three important objectives:
0/980 · 98
29
../../protocols/tls.rst:98
English
Securely negotiate the cryptographic algorithms that will be used by the client and the server over the TLS session
0/1150 · 115
30
../../protocols/tls.rst:100
English
Verify that the client interacts with a valid server
0/520 · 52
31
../../protocols/tls.rst:101
English
Securely agree on the keys that will be used to encrypt and authenticate the messages exchanged over the TLS session
0/1160 · 116
32
../../protocols/tls.rst:105
English
The TLS handshake is a four-way handshake illustrated in the figure below.
0/740 · 74
33
../../protocols/tls.rst:130
English
In a nutshell, the client starts the TLS handshake by proposing a random nonce. The server replies with its random nonce and a certificate that binds its name to a public key. The client generates a MasterSecret that will be used later to derive the session keys and encrypts it with the public key of the server. It also generates a `Finished` message that contains a MAC of all the messages exchanged to allow the server to detect any modification of the messages sent by the client. The server also sends its own `Finished` message. At that point, the client and the server sent encrypted records thanks to the keys derived from the MasterSecret.
0/6490 · 649
34
../../protocols/tls.rst:140
English
Let us first discuss the negotiation of the cryptographic algorithms and parameters. Like all security protocols, TLS includes some agility in its design since new cryptographic algorithms appear over the years and some older algorithms become deprecated once cryptanalysts find flaws. The TLS handshakes starts with the ``ClientHello`` message that is sent by the client. This message carries the following information :
0/4210 · 421