SSL/TLS Brown Bag (Ⅱ)
Currently most of SSL handshakes would use ECDHE as key exchange algorithm. It supported PFS and also is more secure than RSA key exchange algorithm. I will show the handshake process with ECDHE-RSA-AES256-GCM-SHA384 and the version is TLS1.2. Because I'm not interested in cryptography, I will only introduce the process without detailed key calculation.
Firstly let's check the overall packets interaction.
Client Hello
We observe the structure of SSL handshake packets is TLV. Different type of handshake messages have their own structure. And maybe more than one handshake messages in the same TCP packets, so the Length field is necessary.
- Random
Random includes 32 Bytes. First 4 Bytes represents timestamp. Other 28 Bytes represents a random number. But this timestamp isn't validated by peer. It's just a part of random. This field is used by session master key calculation, KDF calculation and the signature of server_key_exchange message.
- Session ID
For a new session, session ID will be 0. If it is not 0, it means client want to resume previous session.
- Cipher Suite
This is a sample of cipher suite. Client will send all cipher suites which it support to server. Server will choose one suitable cipher suite from all cipher suites which sent by client and sent it back to client. Different cipher suites have different security and encryption performance.
- Extension
TLS is newer than SSL. TLS has some new features so they would appear in the form of Extension.
- server_name: SNI
- elliptic_curves/ec_point_formats: List the algorithms which client support.
- status_request: Request OCSP.
- SessionTicket TLS: It is used to resume a session.
Server Hello
This message is used to reply client hello. It confirm the TLS version and cipher suite. Server also will generate another random number and send it to client by server hello. If a session need to be resumed, server hello will carry session ID.
Certificate
Server send server certificates(chain) to client. And then client need validate all certificates.
Server Key Exchange
For DHE/ECDHE key exchange algorithms, server send this message to client. It carries algorithm, Pubkey and a signature. Client will use this Pubkey and random to calculate encryption key. Client also need this signature to validate server own its certificate.
Client Key Exchange
It's similar as server key exchange message. It only send the Pubkey.
Change Cipher Spec Protocol
It meant subsequent messages will be encrypted. It's not a handshake message.
Encrypted Handshake Message
It represent the first encryption message and don't include any useful data.