preface
If you haven’t tried using Wiresharp yet, you can refer to my article on Wiresharp Basics.
This article will not cover TLS in detail, but please watch it in conjunction with my previous article “TLS/SSL Protocol in Depth”.
Handshake
The basic concept
The handshake process in TLS1.2 has three main purposes:
- authenticate
- Reach a security suite consensus
- Pass a key
As shown in the figure:
1. The client sends oneClient Hello
, including:
- Protocol version number.
- Random number generated by client –
Client random
. - List of security suites supported by the client.
The Server returns a Server Hello, including:
server
Selected security suite.server
Send your own digital certificate –server Certificates
.server
Sends its own generated public key –serverKey
.
3. The client sends the generated public key -clientKey. 4. The client and server generate symmetric encryption keys based on their own private keys and each other’s public keys. 5. Encrypt communication
Use wiresharp to capture and analyze packets
The grabwww.juejin.im
For example:
1.Client hello
:
- Protocol Version number
Version: TLS 1.2
- The random number
Random
- A list of 17 security suites supported
2,Server hello
In:
-
Protocol Version Version: TLS 1.2
-
A security suite is selected: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
-
A Random number of Random
-
Sending digital certificate:
-
send
server
The public key and the signature algorithm used:
3,Client
Send your own public key
4. The client and server generate symmetric encryption keys based on their own private keys and each other’s public keys
5,Change Cipher Spec
In this step, the client notifies the server that any subsequent messages will be encrypted using the previously negotiated keyserver
The handshake ends.
6,Change Cipher Spec
In this step, the server notifies the client that any subsequent messages will be encrypted and notifiedclient
The handshake ends.
TLS1.3 handshake
TLS1.3 has significantly reduced the number of security suites supported. For example, only five security suites are supported in openssl1.1
TLS13-AES-256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS-AES-128-GCM-SHA256
TLS-AES-128-CCM-8-SHA256
TLS-AES-128-CCM-SHA256
TLS1.3
Changes to the handshake:
With the reduction of safety kits,client
You can generate a pair of keys for all five security suites on the first requestpublicKey
Sent to theserver
And thenserver
Select one of the security suites to generate your own pair of keys. Thus, the handshake process is reduced by one compared to TLS1.2RTT
.
Optimization of the handshake process
The one or two RTT times consumed in a TLS handshake are for security purposes.
But it doesn’t make sense for information transfer at the application layer.
So TLS provides a number of means to reduce the RTT time consumed during the handshake. For example, session cache and ticket tickets
The session cache
The server generates a sessionID after the first handshake and passes it to the browser.
Within a certain time, such as a few hours, a few days. When the browser visits the server again with the sessionID, the server extracts the encryption key that the sessionID points to from the cache. There is no need to generate a new key from the ECDH protocol again, thus reducing the RTT time consumed.
Take baidu site as an example:
When I visit baidu again,client hello
You carry onesessionID
:
whileclient Hello
It comes straight after the stepsChange Cipher Spec
. Didn’t go throughDH
orECDH
Key exchange protocol
Change Cipher Spec
And it saysClient
, using the previous key
Ticket ticket
withsesion
The mechanism is different,ticket
The mechanics don’t needserver
Cost cache to store. Instead, it is based on a unique password that is shared across the cluster. Based on this password willticket
After decryption, the key generated last time can be obtained.
0RTT handshake in TLS1.3
The so-called 0RTT means that the first request carries GET data and the RESPONSE immediately after one RTT. Handshake time is 0RTT.
In fact, this is also for the second handshake. When you shake hands for the first time,client
withserver
It will cache the key information. During the second access, packets are encrypted based on the information valid within a certain period of time based on the first cache.
Replay attack
Whether it issession
,ticket
orTLS1.3
In the0RTT
All face one danger: replay attacks
As shown in the figure:
If the Client sends a POST request to the server encrypted with the previous key, normally a POST request will change the database.
If the message is captured by a middleman and there is no need to decrypt the message. Then in the subsequent time, continue to send this packet, you can constantly change the database to cause the attack effect.
Therefore, it is necessary to set a proper expiration time.
At the end
For more articles, please go to Github, if you like, please click star, which is also a kind of encouragement to the author.