Wireshark is the underlying network monitoring tool

Full name of the noun

  • HTTPS

HTTP Secure/HTTP over SSL / HTTP over TLS

  • SSL

Secure Socket Layer: Indicates the Secure Socket Layer

  • TLS

Transport Layer Security: Indicates the Transport Layer Security

TLS is a precursor to SSL, which stands for TLS in HTTPS

Two, HTTP+ TLS after the transmission level diagram

Send: HTTP -> TLS -> TCP -> IP -> LINK

Accept: LINK -> IP-> TCP -> TLS -> HTTP

Simple summary: Transport plus a LAYER of TLS encryption layer, acceptance plus a LAYER of TLS decryption layer

Third, nature

Asymmetric encryption is used between the client and the server to negotiate a set of symmetric keys, which are encrypted before each message is sent and decrypted after receiving, realizing encrypted transmission.

  • Why not just use asymmetric encryption?

Asymmetric encryption is a complex algorithm, which will seriously reduce the performance of receiving and sending, and reduce the processing efficiency.

Four, TLS link process

1.Client sends: Client Hello

  • 1. The TLS version
  • Encryption suite: symmetric encryption algorithm, asymmetric encryption algorithm, and hash algorithm
  • 3. Client random number
  • 4. Other information

2.Server: ServerHello

  • 1. Select the TLS version that can be matched
  • 2. Select the encryption suite: symmetric encryption algorithm, asymmetric encryption algorithm, and hash algorithm
  • 3. The other

3.Server send: Server certificate

  • 1. Server certificate (including the certificate signature, public key, host name, and region)
  • 2. Ca certificate information (certificate public key and public key signature)
  • 3. Specify the root certificate information
  • 4. Other information

Validation rules:

  • 1. Use the private key of the CA to sign the hash value of the public key of the server. The public key of the corresponding certificate issuing authority can decrypt the signature and confirm that the server certificate is secure and trusted.
  • 2. Use the public key of the specified root certificate to unlock the signature of the public key of the ca certificate to verify that the CA is secure and trusted
  • After reaching the client, the client validation chain:
    • 1. The client checks whether the root certificate specified by the server is trusted. If the root certificate is trusted, the client uses the public key in the root certificate to decrypt the public key of the issuing authority of the server certificate for signature
    • 2. Use the public key of the issuing authority to decrypt the signature of the public key of the server certificate to ensure that the server certificate is secure and trusted

If one of the above authentication links fails, the TLS link will fail to be established.

The server certificate only proves the owner of the site or domain name, not whether it is legitimate

Using Wireshark to display the following information:

4.Client sends 3 messages in succession:

  • Pre-master secret (encryption using the server public key)
  • Transmission of encrypted messages will begin
  • Finished (encrypted handshake information)

The server uses pre-master Secret to obtain the same encryption key as the client using the same calculation method

At this stage, both ends will hold the following information:

1. Client random number

2. Server random number

3.Pre-master secret random number

4.Master secret (use the same algorithm on both ends to calculate the above three information and get the same result)

Use Master secret to calculate the following symmetric keys:

5. Client encryption key (symmetric key)

6. Server encryption key (symmetric key)

7. Client MAC Secret

8. Server MAC secret

At this point both parties create the transmitted key for symmetric encryption

5.Server sends two messages in succession:

  • Transmission of encrypted messages will begin
  • Finished (encrypted handshake information)

The timing is not necessarily after the last two messages from the client

The information is encrypted and sent to the client. The client verifies the data to ensure the consistency between the two parties.

So far, there are five major steps. When the TLS link is successfully established, the corresponding symmetric encryption key can be used for encryption and transmission.

Fifth, q:

1. What is the function of server random number?

Avoid replay attack: Although the encrypted information can not be solved, the encrypted data sent will be intercepted and repeatedly sent to the server to do damage. For example, the interception is the transfer request, and the replay request will be repeated at another time. Each link after the server random number is not the same, to avoid being replay attacks

2. If the encryption is symmetric, why do the client and the server use different encryption keys?

In order to prevent the data sent out from being sent back intact, the sender and receiver use different keys to avoid this attack

3. If HTTPS is used, why do projects sometimes have to build an internal encryption logic internally

This problem is so large that it is easy to misunderstand it.

  • First, if the certificate used is not 100% trusted, for example, the certificate authority may betray users, betray the country, or be controlled by evil forces. At this point HTTPS is completely disintegrated and meaningless.

Logic is such a logic, but in the domestic basic is nonsense! Not abroad.

If you really don’t trust them, it’s much safer to use a private certificate than to order your own encryption logic, which is less secure than TLS.

Of course this is just my personal understanding, there may be other aspects of knowledge, welcome to comment.

  • Second, HTTPS only encrypts the transport layer and protects against man-in-the-middle attacks. Therefore, the server is passive, and terminals can access it after forged certificates are trusted by the root certificate.

Therefore, after the C end individual is cracked, the server can be damaged in a small scope, or there is a risk of large-scale damage

For example, HTTPS packet capture can steal the interface request parameters and return parameters that can be accessed by a single user, resulting in data security and the risk of specific interfaces being attacked.

Therefore, the server needs to identify illegal requests at the business level based on the private certificates trusted by some sides, as well as replay attacks by single users.

Then consider:

1. Use private certificates, but this will bring high operating costs to the C end. After all, every time the certificate is updated, the C end version must be updated

2. Using symmetric encryption, each request generates a new request signature. In this way, the first server can prevent replay attacks, and the second server can identify whether the visitor is legitimate.

3. Use asymmetric encryption to encrypt the original data and then send it to HTTPS for transmission. This is not worried about catching bags, cracking is not worried. There is only a performance trade-off, usually for extremely sensitive data interaction scenarios such as payments.

END