HTTPS Knowledge Summary

HTTPS Knowledge summary background 1:tcp handshake

Two machines on the internet A, B to establish an HTTP connection, before the first to establish a TCP connection, the scenario is probably this:

• A: Hello, I'll build a TCP with you, okay?
• B: Good.
• A: Let's set up a TCP connection.

There is a joke about TCP on the Internet, which is probably the meaning above. The fact is, of course, more complicated than this:

• A: Hello, I'll build a TCP with you, okay? I'll send you the data (SYN) from the 0x0a00 number.
• B: Good. I started sending data (SYN) from 0x0b00, I received the handshake data you 0x0a00 started, (ACK=0X0A01)
• A: Let's set up a TCP connection. I got the handshake data you 0x0b00 started (ACK=0X0B01)

The TCP handshake is essentially a parameter for a binary communication at one time, allowing two models on the network to Exchange binary data based on the Convention. As we all know, binary data is a bunch of 0 and 1, if there is no prior agreement on the byte length of the division and the meaning of each bit represents, it is impossible to interpret.

Background 2:tls handshake

Or the above scenario, A and B after establishing a TCP connection, but also to establish a TLS connection

• A: Hello, I set up a TLS connection with you, I support the encryption method has a1,a2,a3 ..... My encryption parameters are a10,a11,a12 ...
• B: OK, we select A1 as the encryption method, I choose the parameter is A10, this is my certificate, there is a public key, you take my public key with the above encryption method to encrypt a password to see.
• A: (turn to ask CA, the certificate is legal), OK, I think a password, this is my password with your public key after the result of encryption, Blablabla ...
• B: (with your own private key to decrypt) I know your password is how many, below is your password symmetric encryption after the ciphertext, Lablablab ...

The actual TLS negotiation is more complex than this, exchanging a lot of detail parameters, TLS connection layer Security is to ensure the following three aspects of security

1. not be monitored. Even if a third party receives the ciphertext, it cannot decrypt
2. not be tampered with. If the message has been tampered with, both parties can examine it through a certain method
3. not be impersonating. The object of communication is not counterfeit.

To reach the above three points, the point in detail is to refer to the RFC's

HTTP protocol

HTTPS is a TCP+TLS-based protocol that, for HTTPS communication, is preceded by a TCP handshake and a TLS handshake before HTTPS communication can begin. After shaking hands, A and B are exchanging data.

• A: I want to get (GET) The default document on your root directory, the last modification time of my face cache is 20161201
• B: This document has been modified, I give you the latest document Content bar (200), the content is xxxxxxx, the last modified time is 20161210
• A: I want to get (get) your name /images/logo.png of the document, my face cache last modified time is 20161201
• B: This document has not been modified, you just use the cache as good (304)
• A: I'll send you a copy of the document (POST), which you store in it /upload/file.jpg , the content is xxxxxx
• B: OK, the resources are created (201)

Can see the HTTP1.1 version of the request is basically in the simulation of human dialogue, a response to the two sides to exchange data.

HTTP/2 multiplexing can reduce these

• A: I want to get (GET) The default document on your root directory
• B: OK. I give you a frame, stream (stream) 2 is the content of the document XXXXXX, stream 4 and so on you will also use, is /images/logo.png the content yyyyyy

TLS1.3

TLS1.3 is currently a standard in development. Where the encryption is based on ECDH, not RSA, so we don't have to wait until the server's certificate is sent to start some cryptographic computations. The principle of ECDH can be referenced here. The role of this certificate becomes a checksum, not an encryption. The scene of the TLS1.3 handshake is probably like this.

• A: Hello, I set up a TLS1.3 connection with you, I support the encryption method has a1,a2,a3 ..... My encryption parameters are a10,a11,a12 .... If you choose A1, then ECDH public parameter is A21, if you choose A2, then ECDH public parameter is A22.
• B: I chose A1, my public parameter is B21. Here is my certificate xxxxxxxx

A GET / the following HTTP requests can be made

Even the 0-rtt handshake can be carried out, of course, based on the previous grip.

• A: Hello, I'll establish a TLS1.3 connection with you. I used to shake hands with you, my proof material is as follows xxxxx. I want the default document under your root directory
• B: Ah, it's you, I know. This proves to be effective. We encrypt it with a negotiated encryption method. The contents of my default document are as follows: xxxxxx

It can be seen that this handshake is directly tcp,tls,http Triad, which is also the basic principle of Quic 0-rtt.

Troubleshooting: Unable to verify the first certificate

The front #8 #5 when I was dealing with a network error, only to know some solutions, but also suspected that the problem is not HTTPS, but can not be verified. Later, after learning the knowledge of HTTPS systematically, it is very simple to explain this phenomenon from this knowledge.

Refer to the above TLS handshake, the service side put its own certificate to the client, in principle, the client is to check the validity of the certificate from the CA, one but can not be verified (verify), will report the above error, and strict-ssl=false is to let npm not to verify, NODE_TLS_REJECT_UNAUTHORIZED=0 is to let node-gyp not to verify. So the two sides on the basis of a fake certificate in the HTTPS communication. In turn, it also shows that the agent I'm using has a MITM attack.

Optimizations for other HTTPS

• HSTs: In short, it is in the HTTP connection phase, let the browser walk 307 to HTTPS, rather than walk 302 (more than one RTT), and hsts can cache, pre-read, so that the next time the browser to access the specified site by default to go first https.
• OCSP stapling: Before the TLS handshake, it is mentioned that the client needs to confirm the validity of the certificate to the CA, which is also a complete HTTP request. The OCSP stapling is to send some intermediate data that the confirmation process needs at once to the client, so that the client (ideally) only needs to be verified with the built-in root certificate.
• There are many other optimized content, it is not listed, you can refer to the https://github.com/imweb/IMWeb-Conf-ppt/blob/master/%E3%80%8AHTTPS%E6%9C%80%E4%BD%B3% E5%ae%9e%e8%b7%b5%e3%80%8b-lancelotluo.pdf
• To optimize, you first need to know some basic knowledge, know how the data is transmitted, and then according to these knowledge, phased optimization. Secondly, we should carry out practice and summarize constantly.

HTTPS-based front-end optimization

If a website is deployed with HTTPS, in addition to being more secure, the front end can be optimized based on it

• Service worker: the equivalent of a cache proxy whose life cycle is outside the page and can do something when the page is not loaded.
• HTTP2:HTTP2 's RfC is based on both plaintext (H2C) and ciphertext (H2), but the current browser vendors only support H2, so want to use HTTP2 multiplexing, head compression, etc. to optimize, you must deploy HTTPS.

Reference

https://tools.ietf.org/html/rfc5246
https://tools.ietf.org/html/rfc7540
Https://imququ.com/post/optimize-tls-handshake.html
Https://www.khanacademy.org/computing/computer-science/cryptography/modern-crypt/v/diffie-hellman-key-exchange-part-2
https://github.com/imweb/IMWeb-Conf-ppt/blob/master/%E3%80%8AHTTPS%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5%E3%80% 8b-lancelotluo.pdf

HTTPS Knowledge Summary