-
Notifications
You must be signed in to change notification settings - Fork 1
/
SSL-TLS-Handshake-reference
33 lines (31 loc) · 4.15 KB
/
SSL-TLS-Handshake-reference
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#SSL handshake overview
#
SSL communication consists of a series of messages exchanged between two parties (client and server). The SSL handshake between a client and server consists of nine steps, and appears as follows:
The SSL messages determine the parameters of the encrypted communication channel that the two parties will use. It is important that the client and server agree on the message details, such as the protocol version, cipher suites, secure renegotiation, or client certificate requests. Otherwise the handshake will fail. The SSL handshake has the following messaging components:
ClientHello
When a client first attempts to connect to an SSL server, it initiates the session by sending a ClientHello message to the server. The ClientHello message starts the SSL communication between the two systems. The ClientHello message contains some of the following components:
Version: The version field contains the highest SSL version that the client supports.
Random: A random number generated by the client.
Session ID: An arbitrary sequence of bytes chosen by the server; it identifies a particular SSL session. The client may attempt to resume a previously established session by sending a non-zero session ID.
Cipher suites: Identifies the list of ciphers suites that the client supports.
Compression: Identifies the list of compression methods that the client supports.
ServerHello
If the server is able to find an acceptable set of algorithms, it responds to the ClientHello message with a ServerHello message. The server may use the ServerHellomessage to allow a resumed session. The ServerHello message contains some of the following components:
Version: The version field contains the highest SSL version supported by both the client and server.
Random: A random number generated by the server.
Session ID: Identifies a particular SSL session. If the client sends a non-zero session ID and the server locates a match in its cache, the server will attempt to respond with the same value as was supplied by the client, and resume the session using the same cipher suite.
Cipher suites: Identifies the cipher suite chosen by the server from the list of ciphers that the client supports.
Compression: Identifies the compression method chosen by the server from the list that the client supports.
Certificate
The server sends its Certificate message containing the server's certificate or list of (chain) certificates, depending on the selected cipher suite.
Note: The server may send a ServerKeyExchange message when the server Certificate message does not contain enough data to allow the client to exchange a premaster secret. This is true of some ciphers such as DHE-DSS.
ServerHelloDone
After sending its certificate, the server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
ClientKeyExchange
The client sends the ClientKeyExchange message containing the PreMasterSecret. The PreMasterSecret is sent encrypted using the public key of the server.
ChangeCipherSpec
Both the client and server send the ChangeCipherSpec message after the security parameters have been determined. The ChangeCipherSpec message activates the negotiated SSL options for the session. From this point forward, all messages are authenticated and encrypted. This stage is significant as it indicates that subsequent records will be protected under the newly negotiated CipherSpec and keys.
Finished
Each party sends a Finished message under the new algorithm, keys and secrets. The Finished message indicates that the handshake is complete, and the parties may begin to exchange application layer data.
Resumed SSL sessions
A resumed SSL session implements session identifier (session ID) to re-establish a previously negotiated session. When an SSL handshake is resumed, the client presents the session ID from the previously negotiated session. If the server finds the session ID in its cache and accepts the resumed session, it sends back the same session ID and the parties skip the public key operation. If the server does not accept the resumed session, it issues a new session ID and implements the full SSL handshake. The resumed SSL handshake between a client and server consists of the following steps: