I recently looked at Https again to deepen my understanding
What is the S in HTTPS?
We say HTTPS is an encryption layer on top of HTTP. So this encryption layer is S. Specifically, SSL or TSL. This protocol is supported by both the client and the server. The differences between SSL and TLS are: SSL is an older version, which has been superseded by TSL, and after 2020, TSL protocol versions 1.1 and below will be deprecated in modern browsers, so servers must support 1.1 and above, which is currently 1.2 or 1.3.
TLS 1.0 and 1.1 support will be removed from all major Browsers in early 2020; You’ll need to make sure your Web Server supports TLS 1.2 or 1.3 going forward. developer.mozilla.org/en-US/docs/…
To put it another way: TSL’s predecessor is SSL, and the two are not fundamentally different, but both were designed to solve HTTP encryption problems. Of course, from a technical depth point of view, there is a big difference. It may be necessary to understand the differences between the two from a back-end and operations perspective, but not from a front-end perspective. For a more detailed understanding of the differences between the two, see here. This article does not discuss them in detail.
What problem does HTTPS solve with HTTP?
HTTPS solves two problems: data encryption and identity authentication. Encryption is the original intention, and identity authentication is actually an essential part of encryption. Encryption is easy to understand, but more on identity authentication. Encryption is to protect data from eavesdropping, and identity authentication is to ensure the authenticity of the server accessed by users. Without authentication, if the user’s DNS is hijacked, the user may not be visiting a real server site. When the user is visiting a phishing site, there is no guarantee that your data will not be stolen. This is the problem that authentication addresses (importance).
Is HTTPS symmetric or asymmetric encryption?
I used both. Asymmetric encryption is used in TLS handshake phase and symmetric encryption is used in business data transmission phase. Asymmetric encryption guarantees master secret. Symmetric encryption ensures the speed of data encryption and decryption on both the server and client sides. If symmetric encryption is complete, it is inevitable to negotiate encryption keys during transmission. Encryption does not work if it is intercepted while negotiating the encryption key. Therefore, the master Secert needs to be generated through asymmetric encryption. Once generated, the master Secert can be used to encrypt data to ensure that the content is ciphertext and cannot be cracked.
Why client random and Server Random are required when master-secret is generated?
From the point of view of encryption, only a pre-master is needed, but why do we need to transmit client random and Server Random in plaintext during the handshake phase? Client Random and Server Random plaintext transmissions can be obtained by middlemen. The answer to that question is here.
Client random and Server Random actually prevent replay attacks. That is, if the middleman gets the request traffic, he can see the URL, even though he doesn’t know the content. Based on the URL, he can guess and judge what operation your request is. If it is a traffic that he thinks can be attacked, he can replay the traffic, keep asking the server, make your request to happen multiple times, so as to achieve multiple requests. For example, a user may want to buy only one product, but a middleman may use a replay to trick the server into thinking that the user has purchased the product multiple times. If server Random is required, a different Server Random will be returned for each request of the middleman. Therefore, if the request of the middleman fails to pass the server verification, the above situation will not occur.