This is the first day of my participation in the August More text Challenge. For details, see: August More Text Challenge
Involved in problem
- Tell me about your understanding of HTTPS
- Why is it safer than HTTP
- Why not just use asymmetric or symmetric encryption
- How does the certificate work
- Why do you shake hands? Can you tell us about the TLS handshake process
Occurrence reason and characteristic
HTTPS solves the security problems compared to HTTP
For example, if the header is transmitted in plain text, tampering cannot be verified without integrity check, and there is no effective means to confirm the identity of the communication parties, etc.
Otherwise, it behaves the same as HTTP, such as transmitting content not limited to text, divided into requestor and responder, connection stateless, and so on.
How to keep safe
Security is mainly ensured by SSL/TLS.
HTTPS is used to communicate with SSL/TLS first instead of directly communicating with TCP.
SSL: indicates secure socket Layer. TLS: transport layer security. TLS1.0 is the official standardized version of SSL3.1.
When a connection is established using TLS, a set of encryption algorithms, also known as a cipher suite, is chosen.
Naming format is fixed, usually by key exchange algorithm, signature algorithm, symmetric encryption algorithm, abstract algorithm, to ensure security.
Such as, ECDHE – RSA – AES256 – GCM – SHA384
Security versus solution
Security can be understood from four aspects:
-
Confidentiality, which means only trusted people can access it
Corresponding to the above key exchange algorithm (asymmetric encryption algorithm, often ECDHE) and symmetric encryption algorithm
HTTPS uses mixed encryption and uses asymmetric encryption algorithms to transmit the keys used for symmetric encryption.
Asymmetric encryption, divided into public key and private key, usually based on complex mathematical problems, a large amount of computing; Symmetric encryption, encryption and decryption use the same key, the calculation is fast, but there are security problems when exchanging the key. Hybrid encryption combines the two for maximum benefit.
-
Integrity, which means that the data has not been tampered with during transmission
Corresponding to the above summary algorithm
The requester will generate a summary and attach it to the original text, and the responder will receive the data and make another calculation and comparison to verify that tampering has occurred.
Integrity needs to be subject to confidentiality, otherwise it would be meaningless to tamper with both the summary and the content.
-
Identity authentication: Authenticates the identity of the peer.
-
Non-repudiation, the inability to deny what has already been done.
Identity and non-repudiation, corresponding to the above signature algorithm (asymmetric encryption algorithm, usually RSA).
Using private key encryption, public key decryption, private key encryption text summary, namely digital signature, public key decryption and summary after comparison, to achieve the effect of authentication.
Digital certificates are used to verify the source of the public key, that is, to verify that it is your public key. With the help of a CA certificate authority (CA), the public key is signed (like a real tycoon endorsement).
certificate
Certificates can be divided into DV, OV and EV with increasing reliability.
Free certificates, usually DV, only verify the domain name and do not know the identity of the holder. An OV verifies the identity of the holder, while an EV is more stringent and used by security-intensive sites such as those involved in payments.
A certificate contains information such as the issuer, user, and validity period. The most important information is the public key of the ca and the signature generated by encrypting the digest with the ca’s private key.
From this we can know that the authentication process of the trust chain is as follows:
- Receive A certificate from the server, possibly with other intermediate certificates (to improve security and prevent A nest of ends)
- The certificate of A contains THE public key of B and the signature of B. The signature is decrypted by the public key of B and the summary is obtained. If it is consistent with the result of the summary algorithm directly performed on A, it means that the certificate is issued by B.
- B may have a superior issuing authority, so it will continue to verify to the superior according to the information carried by B certificate
- Until a trusted root certificate is verified, the root certificate is stored directly in the browser or operating system and updated with system updates
Note that the signature of the root certificate is issued by the root certificate itself, and you can only choose trust.
In this case, you can revoke the trust of the CA in the browser or operating system, or use the CRL (Certificate Revocation List) or OCSP(Online Certificate Status Protocol) to find the faulty certificate
The TLS handshake
The primary purpose of a handshake is to securely exchange session keys, which is to do what was mentioned earlier: use asymmetric encryption algorithms to transmit keys for symmetric encryption
In this process, a total of three random numbers (C, S, pre-master) appear, which are mainly used to improve randomness, achieve unpredictability, and improve the difficulty of cracking
According to the choice of key exchange algorithm (that is, asymmetric algorithm), it can be divided into two types.
One is the mainstream use of ECDHE. The client and the server exchange the public key of ECDHE, and the pre-master is calculated by the two public keys using ECDHE. The master key is generated together with the random number of the client and the random number of the server exchanged during the handshake. This form has forward security. The public and private key pairs exchanged during each handshake are temporary, and the hacker only breaks one session after cracking one.
The other is traditional RSA, in which the client directly generates a random number pre-master and passes it using the RSA public key provided by the server. The following process is similar, with three random numbers to generate the master key. Compared with ECDHE, the public key in this way is fixed and easy to crack.
ECDHE handshake process
Super-long legend
- Client to server: TLS version number, random number C, list of optional cipher suites
- Server to client: TLS version number, random number S, selected cipher suite; Certificate; ECDHE public key, with signature;
- The client to the server :(verifies the certificate and signature) the ECDHE public key. (Pre-master is calculated on both sides, and the master key is generated); Change the session key (Change Cipher Spec); Handshake Data Summary (Finished)
- Server to client: Switch to session key; Handshake data summary
RSA Handshake process
Super-long legend
- Client to server: TLS version number, random number C, list of optional cipher suites
- Server to client: TLS version number, random number S, selected cipher suite; certificate
- From the client to the server :(verifies the certificate and signature, and generates the pre-master.) encrypts the pre-master with the RSA public key. (Three random numbers generate the master key); Change the session key (Change Cipher Spec); Handshake Data Summary (Finished)
- Server to client: Switch to session key; Handshake data summary
Thank you
Perspective HTTP protocol YYds! Behind Security: How Browsers verify Certificate recommendations! [SSL] The difference between OV, DV, and EV certificates
This article is a summary after reading the safety section, with a personal understanding section. If there is a misunderstanding, welcome to discuss ~