HTTP is a clear text transmission protocol, and the data is easy to be eavesdropped and tampered with, and attackers can easily pretend to be clients and servers. HTTPS can solve the security problems of these two countries. HTTS is still HTTP protocol, but TSL/SSL protocol is added between HTTP and TCP to encrypt data. Many other application layer protocols have also added TSL/SSL protocol at the transport layer to ensure security, such as FTPS and IMAPS.

Encryption and decryption use the same key. Both encryption and decryption need to hold the same key. Common symmetric encryption algorithms: AES, DES, 3DES.

Encryption and decryption use different keys, the key used in encryption is called public key, and the key used in decryption is called private key. Ciphertext encrypted with public key can only be decrypted with private key. The public key can be released for use, but the private key must not be revealed. Common asymmetric encryption algorithms: RSA, knapsack algorithm, ECC.

Digital signature is used to check whether the data has been tampered, that is, whether the data is consistent with the original data.

Digital signature includes two operations: signature and verification. Digital signature is undeniable, and it cannot be denied after the signature is verified to be correct.

A digital signature usually contains a known private key and a public key. Different from traditional encryption, private key is used when signing, and public key is used to verify the signature.

1994 Netscape proposed SSL protocol, and formulated the original specification of SSL protocol, namely SSL 1.0. However, SSL 1.0 has been questioned by cryptography because of its weak encryption algorithm, so SSL 1.0 has not been published publicly.

Following SSL 1.0, Netscape has made significant improvements to the SLL protocol specification, and published the SSL2.0 protocol in 1995. Although SSL version 2.0 is considered as a very powerful and robust protocol, there are still some vulnerable vulnerabilities, so it has not been widely used.

Because of the security problem of SSL2.0, Netscape and Paul Kocher of Harvard redesigned the SSL protocol and released it in 1996, which is SSL version 2.0, which is very different from version 2.0. SSL 3.0 protocol has been widely recognized and supported by the Internet.

With the rapid development of the Internet, network security is becoming more and more important, and the industry urgently needs a standard security protocol, so IETE took over the SSL protocol and renamed it TSL (Transport Layer Security Protocol), and released the TSL 1.0 version at 1999.

However, there is little difference between TSL 1.0 and SSL3.0 (the protocol version number in TLS 1.0 is actually 3. 1).

Although TSL is an upgraded version of SSL, there is still some confusion in some terms, so people usually call it SSL/TLS protocol.

TSL 1. 1 was released in 2006, mainly to fix some loopholes.

TSL 1.2 was released in 2008. 1.2 version mainly removes some old encryption suites and introduces AEAD encryption mode. 1.2 is the most widely used version at present.

TSL 1.3 was released on 20 18. The version 1.3 was put forward in 20 14, and it was not formally incorporated into the standard until the 28th draft after four years of repeated revisions.

Compared with the 1.2 version, the 1.3 version has changed a lot, which not only enhances the security but also greatly improves the access speed. The main changes are as follows:

In public network communication, in order to ensure the security of communication channels, communication data can only be encrypted at present to prevent eavesdropping, impersonation and tampering.

To prevent eavesdropping:

After the data is encrypted, the encrypted ciphertext is transmitted. Even if the ciphertext is eavesdropped, the real content cannot be obtained without the decryption key.

Anti-counterfeiting and tampering:

When the communication data is encrypted and transmitted, it is impossible to construct legal data packets without encryption keys, so it is impossible to impersonate or tamper with the data.

Encrypted transmission of communication data can solve many security problems, but the key to realize communication encryption is how to negotiate the encryption key to ensure that the key will not be leaked and tampered with. The key protocol is the biggest difficulty of HTTPS.

Symmetric encryption is used in communication, and when the client requests it, the symmetric encryption key is directly returned to the client.

However, before the secure channel is established, any transmission is still plaintext, using plaintext encryption key is not secure, and symmetric encryption uses the same key, so a third party can eavesdrop and tamper with data after eavesdropping on the key, or pretend to be a client and a server. So it is obviously not feasible to distribute symmetric encryption keys directly.

For the convenience of explanation, we only look at the situation that the client sends data to the server in one direction, and the server also sends data to the client in a similar way.

Asymmetric encryption is used in communication. When the client requests the public key, the public key is put back to the client.

However, when the public key is returned, it is still transmitted in clear text, so the public key will still be easily leaked. After the public key is leaked, although the third party can't eavesdrop on the data or directly impersonate the server without the key, the third party can still impersonate the client or carry out' man-in-the-middle' attacks because of the public key leakage.

So it is not feasible to simply use asymmetric encryption.

Man in the middle attack:

As long as the key used in communication is not leaked, there is no need to use asymmetric encryption in communication. After all, symmetric encryption is more efficient. Therefore, before the formal start of communication, asymmetric encryption can be used to negotiate the symmetric encryption key used in communication, and the steps are as follows:

Although the combination of symmetric encryption and asymmetric encryption can give us the advantages of both, it is still impossible to avoid the' man in the middle' attack.

DH key negotiation algorithm does not exchange keys directly, but uses parameters to generate keys. DH algorithm can't decompose large numbers into prime numbers based on the current' inability', so as to ensure that even if the parameters are leaked, the third party can't deduce the key through the parameters.

DH algorithm key negotiation steps:

Through the above steps, the client and the server negotiate the key S, and S is not transmitted in the whole process. To prevent being cracked, A and B are usually large, P is a prime number of at least 300 bits, and G is usually small, usually 3 or 5.

But the shortcomings of DH algorithm are also obvious. DH can't prevent an impostor, and he will still be attacked halfway.

Digital certificate, also known as public key certificate or identity certificate, is used to issue public keys and prove the identity of the public key owner.

This certificate is issued by a third party and used to verify the legitimacy of the service provider. When using, the service provider gives the certificate to the client, and the client verifies the validity of the certificate through a specific mechanism, thus trusting the server providing the certificate and the public key in the certificate.

Digital certificates exist in the form of files, which contain public key information, owner identity information (subject) and digital signature of digital certificate certification authority (issuer). The digital signature of the certificate is used to ensure that the certificate has not been tampered with.

Generally, when we apply for a certificate from CA, we don't need to provide a public key and a private key. CA will assign us a key pair, write the public key into the certificate, and then give us the certificate and the private key.

There is a unified standard for certificates, and their legitimacy (whether the certificate is expired, whether the digital signature is valid, and whether the issuing institution is credible) is verified according to the standard through certain procedures. For example, the browser will ensure that the HTTPS certificate is legal, and the openSSL library under Linux provides the certificate verification function.

After checking the certificate, if the certificate is trustworthy, you can encrypt the data with the public key in the certificate and communicate with the owner of the certificate.

The certificate of HTTPS contains information related to the domain name in the extended field, so CA will strictly check whether the organization or individual applying for the certificate really owns the domain name when applying for the certificate.

Digital Certificate Authority (CA). The standard of certificate is open. Anyone can make a certificate, but the certificate he made is not credible. Only certificates issued by authoritative CA organizations can be trusted.

The deployment process of authoritative CA certificate is rigorous and complicated, so the validity period of authoritative root certificate is generally within several decades.

Only the root certificate of authoritative CA will be supported by major operating systems and prefabricated in the operating system.

Certificates generally follow the X.509 specification and mainly include the following contents:

The certificate generated by CA not only contains the above contents and some extended fields, but also contains the ciphertext encrypted by CA with its own private key. When verifying the certificate, use the root certificate of CA to verify the secret, so as to judge whether the certificate is legal or not.

The issuing authority uses the root certificate to issue a secondary CA certificate, which can issue certificates to other services. However, not all certificates can continue to issue new certificates. Certificates use basic constraint extensions to restrict the issuance of certificates, and the basic constraint extensions we generally apply for are fake. Looking at the basic constraints of the root certificate, you can see that the certification authority is' Yes'.

Root certificates do not directly issue certificates to services as long as they are based on the following two points:

The upper certificate signs the lower certificate, and the signature value is included in the certificate. You can use the public key in the upper certificate to verify the signature value of the lower certificate. The signature of the root certificate is self-signed, and the public key to verify the signature is contained in the root certificate.

The complete certificate company relationship should have been put back by the server, but some of it was not put back. For the certificate that has not been put back, the extension field CA key identifier in the certificate records the last certificate of the certificate, and obtains the upper intermediate certificate through this field, and then continues to search from this field of the intermediate certificate until the root certificate.

It is better for the server to return the certificate link to avoid the browser looking for it itself and prompt the handshake speed. The certificate chain returned by the server does not contain the root certificate, which is pre-stored in the operating system.

Openssl library will integrate root certificate in linux. View the storage path of OpenSSL root certificate through' OpenSSL version-a'.

When checking the certificate, firstly, check the signature of the certificate step by step according to the certificate chain, and the key to the signature check is the root certificate. The root certificate is preloaded in the operating system, and it is difficult for CA to preload its own certificate into various systems, so it is credible to preload the root certificate in the system.

Looking back, for the certificate of HTTPS, CA will strictly verify it when applying to ensure that the domain name belongs to the institution applying for the certificate. In this way, an attacker may forge a certificate to change the domain name, but the root certificate of the forged certificate will not exist in the system, so the forged certificate will not be trusted. In this way, through the verification of certificate chain, the server can be effectively prevented from being "impersonated".

After the digital signature verification of the above certificate, only verify that the certificate is indeed a legal certificate, and then verify the validity of the certificate. Validity verification mainly includes the following fields:

A valid certificate may also be revoked for various reasons, such as the leakage of the private key of the certificate and the wrong issuance of the certificate. In order to verify whether the certificate is valid, a certificate revocation mechanism is introduced.

OSCP is a certificate verification interface provided by the certificate provider, and users can verify whether the certificate has been revoked by calling the OSCP interface.

However, the OCSP service may not be accessible due to policy or service failure. At this time, the general browser will choose the trust certificate. After all, certificates are rarely revoked. There are also some CAs that write the policies after OCSP failure into the extended fields of certificates, and users can handle them according to the extended fields.

OSCP mode has its obvious defects. In order to verify the certificate, when you request OSCP, you also need to tell CA what services you have accessed. What should CA do if we use our access data to do evil? And the slow interface of OCSP will slow down our service for Sudoku. In order to solve these two problems, major CA vendors jointly launched the CRL scheme.

CRL scheme is to pull the list of revoked certificates to this machine regularly, usually once every few days. When verifying the certificate, look it up in the local list.

The CA will write the updated address of the CRL in the extended field of the certificate:

CRL also has its own obvious determination. First, CRL is pulled regularly, which can't guarantee real-time effectiveness, and then the list of CRL is likely to reach several meters.

CRLSet is chrome's self-built solution. Google thinks that CRL update is too slow, and each CA has its own CRL, which contains too much content. So I set up a CRLSet to add the revoked high-risk certificate of the main CA to the CRLSet. Chrome can check the certificate in its CRLSet.

CRLSet only has some certificates revoked by each CA, including about 2% of all revoked certificates.

CRLSet is updated quickly, and it will be updated from each CA every few hours at the latest. When the certificate needs to be revoked urgently, CRLSet can be used to make the revocation take effect quickly.

CRLSet provides /agl/CRLSet-tools tools to extract and verify whether the certificate is in CRLSet.

You can update the CRLSet of chrome in chrome://components/

The client sends a hello request to the server, which includes the SSL/TSL version of the client, the supported encryption suite and the random number Random 1.

After receiving the hello from the client, the server selects the encryption and hash suite to be used later according to the encryption suite supported by the client and the encryption suite supported by itself, and returns it to the client, and at the same time returns the random number Random2 generated by the server.

The server returns its own certificate to the client, and the client trusts the server by checking the certificate after receiving the certificate, and obtains the public key in the certificate from the certificate.

After the certificate is returned, the server will send a request to the client immediately. However, this request is not necessary, and the request interaction parameter will be sent only when the selected encryption suite requires additional parameters.

If the key negotiator algorithm is DH algorithm, the parameters of DH will be returned to the client in this request. DH algorithm is as follows: DHE_DSS, DHE_RSA, ECDHE_ECDSAECDHE_RSA.

The dh algorithm will return the public keys of parameters P, G and dh and their signatures, where the public key is g^b mod p and B is the random number of the server.

Where g is 0X03 and p is 0X00 17.

After the server sends the above information, it will immediately send the server Hello Done to inform the client that the relevant information of the server has been sent, just waiting for the client to start key negotiation.

After receiving the message, the client begins to verify the certificate and negotiate the key.

After receiving the server Hello Done information from the server, the customer accountant calculates the preliminary master key and returns it to the server.

If RSA/ECDSA algorithm is used, the prepared master key is sent.

If DH algorithm is used, the public key of the previous parameter statistics is sent, that is, the B (G b mod P) server gets the third random number through B a mod P after receiving B, and the client gets S through s = A b mod.

At this point, the server and the client have obtained three random numbers, and a symmetric encryption key is obtained by using these three random numbers through the previously negotiated encryption algorithm, which will be used in future communication.

This request is used to inform the other party that the key used for communication has been counted, and all subsequent communications will be conducted with this key. Both the server and the client send requests, usually the server sends them first.

After completing the above steps, both sending parties will send a completion request to the other party, and the completed data will be encrypted with the negotiated key to verify whether the previously negotiated key and protocol version are valid.

References: