TLS Handshake Flow（extracts from RFCs）

Abstract

The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping（窃听）, tampering（篡改）, or message forgery（伪造）.

The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol.

Standard

• rfc2246: Version 1.0
• rfc4346: Version 1.1
• rfc5246: Version 1.2

Handshake

The TLS Handshake Protocol involves the following steps:

• Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption.
• Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret.
• Exchange certificates and cryptographic information to allow the client and server to authenticate themselves.
• Generate a master secret from the premaster secret and exchanged random values.
• Provide security parameters to the record layer.
• Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker.

双因素认证（the parties are mutually authenticated）:

在某些场合，服务器也要求对客户端进行身份验证——CertificateRequest*+。
如运行招行专业版客户端，需要插入优KEY（U盾）提供证明客户身份的移动数字证书（Certificate*+），方可登录网银。
并且会发送一个证书校验（CertificateVerify*+）消息以证明在服务器要求客户端验证身份的情况下自己拥有与之前提供证书（公钥）对应的私钥。

resumed from Session ID

session identifier: An arbitrary byte sequence chosen by the server to identify an active or resumable session state.
“Server Hello” message contains a 32 byte session ID in case we want to reconnect without a big handshake.

The client sends a ClientHello using the Session ID of the session to be resumed.
The server then checks its session cache for a match.

If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value.
At this point, both client and server MUST send ChangeCipherSpec messages and proceed directly to Finished messages.
Once the re-establishment is complete, the client and server MAY begin to exchange application layer data.

If a Session ID match is not found, the server generates a new session ID, and the TLS client and server perform a full handshake.

Extensions

rfc3546/rfc4366: Transport Layer Security (TLS) Extensions

rfc4680: TLS Handshake Message for Supplemental Data

1. Message Flow with SupplementalData  
2. Double Handshake to Protect Supplemental Data  

rfc4681: TLS User Mapping Extension
rfc5746: Transport Layer Security (TLS) Renegotiation Indication Extension

ECDH

rfc4492: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)

rfc5289: TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)

rfc7919: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

Server Certificate

参考

The SSL/TLS Handshake: an Overview

An overview of the SSL or TLS handshake