Understand the TLS process of HTTPS

preface

Do TCP three-way handshake or TLS certificate verification precede HTTPS?

Is the RSA encryption algorithm used for key negotiation in HTTPS?

For these two problems, read a lot of blogs, write inconsistent, today to their own verification!

Prepare analysis tools

`WireShark`introduce

A packet capture network analysis software, can intercept all kinds of network packets.

Through it you can see the physical layer, data link layer, IP layer, TCP layer, TLS layer, HTTP layer data information.

Therefore, we are going to use the WireShark tool this time to try to see the actual process including TCP.

PS: Charles is probably the most familiar one, but the principle of Charles relies on the way of middleman to present the information of request and response. We can only see the information at the application level, but cannot explore further information, so it is not used here.

WireShark download address

`WireShark`use

The opening interface is as follows:

Click Capture Options:

Select the port to listen on and click “Start”

You can see all the TCP information and so on.

But here we decided not to use computers to catch bags. Because the computer supports many processes, interference information is too much, see dazzling.

The iPhone has the option to open only one app for easy analysis.

IPhone usage`WireShark`caught

Step one: Get the equipment`udid`

If you have Xcode on your computer: Connect your phone to your computer, open Xcode, and select Window -> Device and Simulators.
If not, use a third-party service. For example, dandelion can obtain UDID, fir. Im can obtain UDID.

Then perform

Rvictl-s iPhone device IDCopy the code

(PS: RVICtl-x device ID is to close the connection.)

choose`wireshark`In the`Cature Option`In the`riv0`

Then open any App on your phone and you can view the information inside.

The analysis process

From the above information, we can see the information exchange between Client and Server before sending data:

Here’s the answer to the first question:

After the connection is established, the TLS handshake is started (many blogs here are wrong).

Why is there a TCP data transfer before Server Hello, certificate exchange, etc?

The exchange of certificate information is transmitted based on THE TCP connection. Therefore, a TCP connection must be established first and the certificate information must be transmitted through the TCP channel.

You can see it in the picture aboveServer HelloThe aboveTCPThe serial number andServer HelloAfter PMTCPThe serial numbers are consistent

TLS handshake details

Client Hello

The Client needs to tell each other its TLS version, supported password suite, and generated random number

Server Hello

The Server tells the other party the TLS version it confirms, the random number, and the selected password suite

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Key negotiation algorithm: ECDHE signature algorithm: AES-128 is used for communication after RSA handshake. SHA384 is used for packet mode GCM digest algorithmCopy the code

Certificate, Server Key Exchange, Server Hello Done

1. The Server provides the peer with its own certificate to identify the peer. The certificate is encrypted using SHA256 digest and RSA. 2. Exchange keys. Tell the other person about the ECDHE algorithm. 3. Send the Server Hello Done messageCopy the code

Client Key Exchange, Change Cipher Spec, Encrypted HandShake Message

1. The Client verifies the certificate of the peer to check whether it is valid

2. Exchange keys and tell each other their information in the ECDHE algorithm

3. Generate the final session key based on the shared key calculated by the random number on the client, random number on the server, and ECDHE algorithm.

4. Inform the other party and use the symmetric encryption algorithm to communicate.

5. Send Encryted Handshake Message, make a summary of the data sent before, encrypt it with the symmetric key, let the server do the authentication.
Change Cipher Spec, Encrypted Handshake Message

According to the information in the ECDHE, the Server also calculates the session key and sends the two messages to the other side.

If both parties verify that it is ok, the handshake is officially complete.

In the preceding information, you can see the ECDHE algorithm used by the key negotiation algorithm. At present, ECDHE algorithm is mostly used for key negotiation. RSA is abandoned because of its lack of forward security.

With the ECDHE algorithm, each certificate negotiation is randomly generated information. Even if the encryption is broken this time, it will not affect the security of other requests. But if RSA is used once, then all requests are not secure until the public and private keys are changed.

The problem

Why add TLS layer?

HTTP protocol is plaintext transmission, and does not verify the identity of the other party, easy to be hijacked, tampering, middleman interception, information leakage and so on.

So it’s important to include protection.

Why not just use symmetric encryption?

Symmetric encryption algorithm. For example, AES algorithm: high security, good performance.

But the big question is: how to get the key to the other party?

First, it cannot be built into the Client because the key can be easily obtained. And it cannot be replaced in real time.

So find a way to transmit it.

But how to ensure secure transmission of key information?

Why not all use asymmetric encryption?

Asymmetric encryption, very secure. The public key can decrypt the data encrypted by the private key, and the private key can decrypt the data encrypted by the public key.

The public key is public, so the problem of passing the public key is solved.

But asymmetric encryption algorithm, performance digestion is greater than symmetric encryption, not suitable for real-time data transmission encryption and decryption.

So you can use hybrid encryption. Asymmetric encryption is used for public key transfer and symmetric encryption algorithm is used for subsequent data encryption and decryption.

Why the digest algorithm?

Abstract The algorithm can summarize the transmitted content, and this process is irreversible. It can be used to prevent content from being tampered and ensure the integrity of content.

But this approach only solves the problem of data communication. How do you make sure that the person you’re negotiating the key with is who you think you are?

If a person impersonates a Server to communicate with you, then your data is not all in the hands of others? So, the Client can’t trust anyone. So how do we do that?

Third-party Certificate Authority (CA)

It is like the public security Bureau, the Ministry of Education and the notary center in the network world. It has high credibility. It signs each public key with its own reputation to ensure that the public key can not be forged and is credible. CA’s signature authentication of the public key is also in a format. It is not simply bound to the identity of the holder, but also includes serial number, purpose, issuer, validity time, etc. These are put into a package and then signed to prove all kinds of information associated with the public key completely, forming a “digital Certificate”.

But you need to make sure that the CA is fine.

There are two problems with it.

A CA – based certificate that may be incorrect, expired, or invalid.

This can be resolved using CRL (Certificate Revocation List) and OCSP (online Certificate Status).
Hackers have compromised the CA

The operating system or browser must revoke trust in the CA.

How does an APP on an iPhone verify a certificate from a server?

Here we look through the AFNetworking code as an entry point.

EvaluateServerTrust :(SecTrustRef)serverTrust forDomain:(NSString *)domain

This is verified by the AFServerTrustIsValid function.

This step is verified by the system's 'SecTrustEvaluate' function.Copy the code

Here is the information about this function:

Cached results are accessed first, followed by network access to the certificate information and revocation list.

This is a time-consuming operation, which involves an optimization point of HTTPS (using the server to perform OCSP periodically and then return the information to the application, thus eliminating the Client’s frequent verification).

System certificate information, feel apple will periodically request to obtain. In the process of packet capture, this request is often found occasionally:

The certificate information should be periodically updated to the local PC.

Here is the TLS process for HTTPS.

References:

preface

Prepare analysis tools

WireSharkintroduce

WireSharkuse

IPhone usageWireSharkcaught

Step one: Get the equipmentudid