The SSL/TLS handshake

The TLS Handshake Protocol is responsible for the authentication and key exchange necessary to establish or resume a secure session. Handshake Protocol manages the following:

  • Client and server will agree on cipher suite negotiation, random value exchange, and session creation/resumption
  • Client and server will arrive at the pre-master secret
  • Client and server will exchange their certificate to verify themselves with the client (optional)
  • Generating the master secret from the pre-master secret and exchanging it

Types of handshake message

There are ten types of message, as shown in the following table, and their corresponding Wireshark filters. This is a one-byte field in the Handshake Protocol:

Type

Protocol

Message

Wireshark content type

Wireshark filter

0

Handshake

Hello request

ssl.record.content_type == 22

ssl.handshake.type == 0

1

Client Hello

ssl.handshake.type == 1

2

Server Hello

ssl.handshake.type == 2

11

Certificate

ssl.handshake.type == 11

12

ServerKeyExchange

ssl.handshake.type == 12

13

CertificateRequest

ssl.handshake.type == 13

14

ServerHelloDone

ssl.handshake.type == 14

15

Certificate Verify

ssl.handshake.type == 15

16

Client Key Exchange

ssl.handshake.type == 16

20

Finished

ssl.handshake.type == 20

 

ChangeCipherSpec

 

ssl.record.content_type == 20

 

Application Data

ssl.record.content_type == 23

Alert Protocol

ssl.record.content_type == 21

The TLS Handshake Protocol involves the following steps in four phases; the prerequisite is that a TCP connection should be established:

Types of handshake message

Open the file two-way-handshake.pcap, which is an example demonstrating a SSL mutual authentication procedure:

Types of handshake message

Client Hello

The TLS handshake starts with the Client Hello message (ssl.handshake.type == 1), as shown in the following screenshot:

Client Hello

Handshake records are identified as hex byte 0x16=22. The structure of the Client Hello message is as follows:

  • Message: The Client Hello message 0x01.
  • Version: The hex byte 0x0303 means it's TLS 1.2; note 0x300 =SSL3.0.
  • Random:
    • gmt_unix_time: The current time and date in standard UNIX 32-bit format
    • Random bytes: 28 bytes generated by the secure random number
  • Session ID: The hex byte 0x00 shows the session ID as empty; this means no session is available and generates new security parameters.
  • Cipher suites: The client will provide a list of supported cipher suites to the server; the first cipher suite in the list is the client-preferred (the strongest) one. The server will pick the cipher suites based on its preferences, the only condition being that the server must have client-offered cipher suites otherwise the server will raise an alert/fatal message and close the connection:
    Client Hello
  • Compression methods: The client will list the compression methods it supports.
  • Extensions: The client makes use of the extension to request extended functionality from the server; in this case the client has requested four extensions, as shown in the following table:

Value

Extension name

Reference

0

elliptic_curve

RFC4492

1

ec_point_formats

RFC4492

3

signature_algorithms

RFC 5246

5

heartbeat

RFC 6520

Note

For a complete list of TLS extensions, visit: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml.

Server Hello

The server will send the Server Hello message (ssl.handshake.type == 2) in response to the Client Hello, as shown in the following screenshot. The message structure of the Client Hello and Server Hello message is the same, with one difference—the server can select only one cipher suite:

Server Hello

Handshake records are identified as hex byte 0x16=22. The structure of the Server Hello message is:

  • Handshake Type: The hex byte 0x02=2 shows the Server Hello message
  • Version: The hex byte 0x0303 shows TLS 1.2 has been accepted by the server

    Server/client

    SSLv2

    SSLv3

    SSLv23

    TLSv1

    TLSv1.1

    TLSv1.2

    SSLv2

    Y

    N

    Y

    N

    N

    N

    SSLv3

    N

    Y

    Y

    N

    N

    N

    SSLv23

    N

    Y

    Y

    Y

    Y

    Y

    TLSv1

    N

    N

    Y

    Y

    N

    N

    TLSv1.1

    N

    N

    Y

    N

    Y

    N

    TLSv1.2

    N

    N

    Y

    N

    N

    Y

The following table shows which SSL version of the client can connect to which SSL version of the server:

  • Session ID: A 32-byte session ID is created for reconnection purposes without a handshake
  • Cipher suite: The server has picked Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030), which means use Elliptic curve Diffie-Hellman (ECDHE) key exchange, RSA for authentication, Block cipher Galois/Counter Mode (GCM), AES-256 for encryption, and SHA-384 for digests
  • Extensions: A response with extension info is requested in the Client Hello message

Server certificate

After the Server Hello message is sent, the server should send a X.509 server certificate (ssl.handshake.type == 11). The certificate configured on the server are signed by the CA or intermediate CA, or can be self-signed based on your deployment:

Server certificate

If a SSL/TLS server is configured with the certificate chain then the entire chain will be presented to the client along with the server certificate. The client (a browser or any other SSL/TLS client) can then check the highest certificate in the chain with stored CA certificates; typically, modern Web browsers have the root CA installed from the trusted CA provider.

The given certificate is signed with the relevant signature (sha256WithRSAEncryption); in this case, the hash value itself is concatenated into the OID (Algorithm Id: 1.2.840.113549.1.1.11) representing the signing algorithm. The certificate follows the DER encoding format and when encrypted becomes PKCS#7, the Cryptographic Message Syntax Standard (refer to RFC 2315).

Server Key Exchange

From RFC #5246, the server sends the Server Key Exchange message (ssl.handshake.type == 12) only when the Server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret:

Server Key Exchange

As you can see in the preceding screenshot:

  • Cipher suites contains key exchange algorithms
  • The Server Key Exchange message will be sent for the following key exchange methods: DHE_DSS, DHE_RSA,DH_anon
  • In line with RFC#5246, the use of Server Key Exchange is not legal for these key exchange methods: RSA, DH_DSS, DH_RSA

Client certificate request

The server can optionally ask client to verify its certificate. To support mutual authentication, the server will send the certificate request message (ssl.handshake.type == 13) to the client and the client must provide its certificate information to the server. If the client fails to provide it, an Alert protocol will be generated and the connection will terminate.

Server Hello Done

The Server Hello Done message means that the server is done sending messages to support the key exchange, and the client can proceed with its phase of the key exchange:

Server Hello Done

Client certificate

The client will send its certificate (ssl.handshake.type == 11) only in a mutual authentication condition. The server will verify the certificate in its CA chain. If the server fails to verify client_certificate, the server will raise an alert fatal protocol and communication will stop:

Client certificate

Client Key Exchange

In the case of the normal handshake process (one way auth), the Client Key Exchange message is the first message sent by the client after it receives the Server Hello Done message.

This Client Key Exchange message (ssl.handshake.type == 16) will always be sent by the client. When this message is seen, pre_master_secret is set, either by transmission of the RSA-encrypted secret or by the Diffie-Hellman parameters, depending on the key exchange method chosen. The server uses its private key to decrypt premaster_secret:

Client Key Exchange

Client Certificate Verify

The Client Certificate Verify message will be sent after the Client Key Exchange message (ssl.handshake.type == 16) using master_secret generated by pre_master_secret.

Change Cipher Spec

The Change Cipher Spec record type (ssl.record.content_type == 20) is different from the handshake record type (ssl.record.content_type == 22) and it's a part of the Change Cipher Spec protocol. The Change Cipher Spec message is sent by both the client and server only when key_exchange is completed and it indicates to the receiving party that subsequent records will be protected under the newly negotiated Change Cipher Spec and keys (master_secret):

Change Cipher Spec

Finished

The Finished (ssl.record.content_type == 22) message is encrypted so it will be an encrypted handshake message in Wireshark. This message is sent immediately after a Change Cipher Spec message from both the client and server to verify that the key exchange and authentication processes were successful. This message contain the MD5 hash +SHA hash. When both the client and server have sent the Finished message, the TLS handshake is considered to have finished successfully and now sending and receiving application data over the secure channel can begin:

Finished

Application Data

The Application Data message (ssl.record.content_type == 23) is carried by the record layer and fragmented, compressed, and encrypted:

Application Data

Record layer processing involves the mentioned step as shown in the following screenshot:

Application Data

Alert Protocol

The Alert Protocol (ssl.record.content_type == 21) describes the severity of the message and the alert. Alert messages are encrypted and compressed and support two alert levels: warning and fatal. In the case of fatal alerts, the connection will be terminated.

Alert descriptions are shown in the following table:

Alert name

Alert type

Description

close_notify(0)

Closure alert

Sender will not send any more messages on this connection

unexpected_message(10)

Fatal

An inappropriate message was received

bad_record_mac(20)

Fatal

Incorrect MAC received

decryption_failed(21)

Fatal

TLS Cipher text decrypted in an invalid way

record_overflow(22)

Fatal

Message size is more than 2^14+2048 bytes

decompression_failure(30)

Fatal

Invalid input received

handshake_failure(40)

Fatal

Sender unable to finalize the handshake

bad_certificate(42)

Fatal

Received corrupted certificate; bad ASN sequence

unsupported_certificate(43)

Fatal

Certificate type is not supported

certificate_revoked(44)

Warning

Signer has revoked the certificate

certificate_expired(45)

Warning

The certificate is not valid

certificate_unknown(46)

Warning

Certificate unknown

illegal_parameter(47)

Fatal

TLV contain invalid parameters

unknown_ca(48)

Fatal

CA chain couldn't be located

access_denied(49)

Fatal

Certificate is valid, the server denied the negotiation

decode_error(50)

Fatal

The TLV received does not have a valid form

decrypt_error(51)

Fatal

Decryption cipher invalid

export_restriction(60)

Fatal

A negotiation not in compliance with export restrictions was detected

protocol_version(70)

Fatal

The selected protocol version is not supported by the server

insufficient_security(71)

Fatal

Strong cipher suite needed

internal_error(80)

Fatal

Server-related issue

user_canceled(90)

Fatal

Client cancelled the operation

no_renegotiation(100)

Fatal

Server is not able to negotiate the handshake

As shown in the following screenshot, the Alert Protocol is generated by the server:

Alert Protocol
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.110.17