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:

  • serverSelected security suite.
  • serverSend your own digital certificate –server Certificates.
  • serverSends 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.imFor example:

1.Client hello:

  • Protocol Version numberVersion: TLS 1.2
  • The random numberRandom
  • A list of 17 security suites supported

2,Server helloIn:

  • 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:

  • sendserverThe public key and the signature algorithm used:

3,ClientSend 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 SpecIn this step, the client notifies the server that any subsequent messages will be encrypted using the previously negotiated keyserverThe handshake ends.

6,Change Cipher SpecIn this step, the server notifies the client that any subsequent messages will be encrypted and notifiedclientThe 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.3Changes to the handshake:

With the reduction of safety kits,clientYou can generate a pair of keys for all five security suites on the first requestpublicKeySent to theserverAnd thenserverSelect 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 helloYou carry onesessionID:

whileclient HelloIt comes straight after the stepsChange Cipher Spec. Didn’t go throughDHorECDHKey exchange protocol

Change Cipher SpecAnd it saysClient, using the previous key

Ticket ticket

withsesionThe mechanism is different,ticketThe mechanics don’t needserverCost cache to store. Instead, it is based on a unique password that is shared across the cluster. Based on this password willticketAfter 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,clientwithserverIt 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,ticketorTLS1.3In the0RTTAll 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.