The principle of HTTPS (SSL/TLS) in layman

Note: This article refers to a number of HTTPS related articles from the network, I according to their own understanding, make some changes, synthesis.

1. Essential Encryption and decryption basics

1) symmetric encryption algorithm: encryption and decryption using the same key encryption algorithm. Because the encryption party and the decryption party use the same key, so called symmetric encryption, also known as the single-key encryption method.

The advantage is that the encryption and decryption operations are fast, so the symmetric encryption algorithm is usually used when the message sender needs to encrypt large amounts of data;

The disadvantage is that the security is poor, if one party's key is compromised, then the entire communication will be cracked. In addition, both sides need to synchronize the key before encryption;

Common symmetric encryption algorithms are: DES, 3DES, Tdea, Blowfish, RC2, RC4, RC5, Idea, skipjack, AES, etc.

2) Asymmetric encryption algorithm: While the asymmetric encryption algorithm requires two keys for encryption and decryption, the two keys are the public key, which is publicly key, the public key, and the private key, which is referred to as the secret key (private key).

The public key and private key are a pair: the public key is used for encryption, the private key is decrypted, and the public key is public, the private key is saved by itself, and the secret key is not required to be synchronized before communication like symmetric encryption.

A bit: Security is better, the private key is saved by itself, do not need to be like symmetric encryption before the communication must first synchronize the secret key.

The disadvantage is that encryption and decryption take a long time, slow, and are only suitable for encrypting small amounts of data.

Commonly used asymmetric encryption algorithms are: RSA, Elgamal, Rabin, d-h, ECC and so on;

3) hash algorithm: Also known as Message digest algorithm. The binary value of any length is mapped to a shorter fixed-length binary value, which is called a hash value.

It is often used to verify the integrity of the data and the test data has not been tampered with. Common MD5 (MD series), SHA-1 (SHA series)

HTTPS uses all of the above three encryption algorithms .

2. the role of HTTPS

HTTP communications that do not use SSL/TLS are non-encrypted traffic. All information is transmitted in plaintext, bringing three major risks.

(1) eavesdropping risk (eavesdropping): Third parties can learn the content of the communication.

(2) tamper risk (tampering): Third parties may modify the content of the communication.

(3) impersonation Risk (pretending): A third party may participate in the communication by impersonating another person.

The SSL/TLS protocol is designed to address these three risks and is expected to achieve:

(1) All information is encrypted and third parties cannot eavesdrop.

(2) has a calibration mechanism , once tampered with, the communication parties will immediately find.

(3) equipped with identity card to prevent identity being impersonating.

The Internet is an open environment, both sides of the communication are unknown identities, which has brought great difficulty to the design of the protocol. Moreover, the Protocol must be able to withstand all the unthinkable attacks, which makes the SSL/TLS protocol extremely complex.

3. History of HTTPS

The history of Internet encrypted communication protocols is almost as long as the Internet.

In 1994, Netscape Company designed the 1.0 version of the SSL protocol (Secure Sockets Layer), but it was not released.

In 1995, Netscape released SSL version 2.0 and soon found a serious loophole.

In 1996, the SSL 3.0 version was introduced, and was widely used.

1999, the Internet Standardization organization ISOC replaced Netscape Company, released the SSL upgrade version of TLS version 1.0.

In 2006 and 2008, TLS was upgraded two times, respectively, for TLS version 1.1 and TLS 1.2. The latest change is the 2011 revision of the TLS 1.2.

Currently, the most widely used is TLS 1.0, followed by SSL 3.0. However, the majority of browsers have implemented TLS 1.2 support.

TLS 1.0 is typically marked as SSL 3.1,TLS 1.1 for SSL 3.2,tls 1.2 for SSL 3.3.

4. Basic Operating Procedures

Basic operating Procedures for HTTPS:

1) using symmetric encryption algorithm to encrypt Web page content , how to ensure the secret key of symmetric encryption algorithm security?

2) using asymmetric encryption algorithm to obtain the secret key of symmetric encryption algorithm, so as to ensure the security of the secret key of symmetric encryption algorithm, and ensure the security of symmetric encryption algorithm .

The principle of this arrangement is that the advantages of symmetric encryption algorithm and asymmetric encryption algorithm are used, and their shortcomings are avoided. The advantage of the symmetric encryption algorithm is fast and the non-symmetric encryption algorithm is secure, meanwhile, the non-security of symmetric encryption algorithm is avoided, and the disadvantage of synchronizing key is avoided, and the slow speed of asymmetric encryption algorithm is eliminated. It's really ingenious.

Here are two questions:

(1) How to ensure the asymmetric encryption algorithm public key is not tampered with?

WORKAROUND: Place the public key in the digital certificate. As long as the certificate is trustworthy, the public key is trustworthy.

(2) Public key encryption calculation is too large, how to reduce the elapsed time?

WORKAROUND: Every session, the client and server generate a "conversation key" (Session key), which is used to encrypt the information. Because the "conversation key" is a symmetric encryption algorithm, the operation speed is very fast, and the server public key is only used to encrypt the "conversation key" itself, which reduces the time spent on cryptographic operations. (That is, the encryption of Web content uses symmetric encryption algorithm)

Therefore, the basic process of the SSL/TLS protocol is this:

(1) The client requests and verifies the public key of the asymmetric encryption algorithm to the server side.

(2) The two parties negotiate a "dialog key" to generate a symmetric cryptographic algorithm.

(3) The two sides use the symmetric encryption algorithm and its "dialogue key" for encrypted communication.

The first two steps of the above process, also known as the "handshake phase" (handshake).

5. detailed process of the handshake phase

The "handshake phase" involves four communications, and we look at it from a single point. It is important to note that all communication in the "handshake phase" is clear text.

1) client makes a request (ClientHello)

First, the client (usually the browser) sends a request for encrypted communication to the server, which is called a ClientHello request.

In this step, the client mainly provides the following information to the server.

(1) The version of the SSL/TLS protocol supported by the browser, such as TLS version 1.0.

(2) A random number generated by a browser client, which is later used to generate a "dialog key" for the symmetric encryption algorithm.

(3) Various encryption methods supported by the browser, symmetric, asymmetric, hash algorithm. such as RSA asymmetric Encryption algorithm, DES symmetric encryption algorithm, SHA-1 hash algorithm.

(4) The compression method supported by the browser.

It is important to note that the server's domain name is not included in the information sent by the client. That is, theoretically the server can contain only one Web site, otherwise it will not be able to tell the client which Web site's digital certificate should be provided. This is why there is usually only one digital certificate for a single server.

This is certainly inconvenient for users of virtual hosts. In 2006, the TLS protocol added a server name indication extension that allowed the client to provide the server with the domain name it requested.

2) server response (Severhello)

After the server receives the client request, it sends a response to the client, called Severhello. The server's response contains the following content.

(1) Confirm the version of the encrypted communication protocol used, such as the TLS 1.0 version. If the browser does not match the version supported by the server, the server turns off encrypted communication.

(2) A random number generated by a server that is later used to generate a "dialog key" for a symmetric cryptographic algorithm.

(3) Confirm the use of various encryption methods, such as validation algorithm use: RSA Asymmetric encryption algorithm, DES symmetric encryption algorithm, SHA-1 hash algorithm

(4) Server certificate.

In addition to the above information, if the server needs to confirm the identity of the client, it will include a request to provide the client with a "client certificate". For example, financial institutions often allow only authenticated customers to connect to their network, and they will provide a USB key to the official customer, which contains a client certificate.

3) Client Response

After the client receives the server response, the server certificate is first validated. If the certificate is not issued by a trusted authority, or if the domain name in the certificate is inconsistent with the actual domain name, or if the certificate has expired, a warning is displayed to the visitor to choose whether or not to continue communicating.

If there is no problem with the certificate, the client will remove the public key of the server's asymmetric encryption algorithm from the certificate. Then, send the following three messages to the server.

(1) a random number. The random number is encrypted using an asymmetric encryption algorithm from the server's public key to prevent eavesdropping.

(2) Code change notification, indicating that subsequent information will be sent with mutually agreed encryption method and key (such as confirm use: RSA asymmetric, des symmetric, SHA-1 hash algorithm).

(3) The Client handshake end notification indicates that the client's handshake phase has ended. This is also the hash value of all the content that was sent earlier, and is used for server verification.

The first random number above is the third random number that appears in the entire handshake phase, also known as "Pre-master key". With it, the client and server have three random numbers at the same time, and then both sides use the previously agreed symmetric encryption algorithm to generate the same "session key" used for this session. In other words, the browser and the server each use the same symmetric encryption algorithm, the three same random number is encrypted, obtained, used to encrypt the web content of the symmetric encryption algorithm key. (Note: Here the browser's three random numbers are clear, but the service side obtained "Pre-master key" is ciphertext, so the server needs to use the private key of the asymmetric encryption algorithm, to first decrypt the "Pre-master key" plaintext, in order to generate a symmetric encryption algorithm secret key. The purpose of this is to prevent: "Pre-master key" is bugged , because the sending of plaintext will be bugged, but the encryption of the non-symmetric encryption algorithm after the ciphertext, because the eavesdroppers do not know the private key, so even if the eavesdropping, it can not decrypt the corresponding plaintext. This guarantees the security of the secret key of the symmetric encryption algorithm used to encrypt the content of Web pages !!! )

As for why it is important to generate a "session key" with three random numbers, dog250 explains it well:

"Both the client and the server require a random number so that the generated key will not be the same every time." Because the certificate is static in the SSL protocol, it is necessary to introduce a stochastic factor to guarantee the randomness of the negotiated key.

For RSA key exchange algorithm, the Pre-master-key itself is a random number, plus the random in the Hello message, three random numbers through a key exporter to finally export a symmetric key.

The presence of the pre master is that the SSL protocol does not trust each host to produce a completely random random number, and if the random number is not random, then the pre-master secret may be guessed, then only the pre-master secret as the key is inappropriate, Therefore must introduce the new random factor, then the client and the server together with the pre master secret three random numbers generated together the key is not easy to be guessed, a pseudo-random may completely not random, but is three pseudo-random is very close to random, each increases one degree of freedom, the randomness increases is not one. "

Here: In fact, if Pre-master-key and browser generated random numbers can be guessed, then the last generation of symmetric encryption algorithm secret key is not safe. Because three random numbers can be overheard.

Additionally, if the server requires a client certificate in the previous step, the client sends the certificate and related information in this step.

4) Final response of the server

After the server receives the third random number of the client Pre-master key, the session key for the symmetric cryptographic algorithm used to generate this session is computed. Then, the following message is sent to the client at the end.

(1) Code change notification, indicating that subsequent information will be encrypted with mutually agreed symmetric encryption algorithm and key.

(2) The server Handshake end notification indicates that the server's handshake phase has ended. This is also the hash value of all the content that was sent before, which is used for client verification.

At this point, the entire handshake phase is all over. Next, the client and the server into encrypted communication, it is completely using the normal HTTP protocol, but with "session key" encryption content.

Reference links

• MicroSoft TechNet, SSL/TLS in Detail
• Jeff Moser, the first Few Milliseconds of an HTTPS Connection
• Wikipedia, Transport Layer Security
• Stackexchange, how do does SSL work?

Finish

=======================================

Note :

This paper mainly modifies from: an overview of the operating mechanism of SSL/TLS protocol

Just install your own understanding, make some modifications, and supplement to facilitate your own understanding. There may be errors in your own understanding.

In addition reference: HTTPS those things (one) HTTPS principle

Summary :

1) HTTPS uses the asymmetric encryption algorithm, symmetric encryption algorithm, hash algorithm, respectively, to use their advantages, to avoid their shortcomings. using asymmetric encryption algorithm to obtain the secret key of symmetric encryption algorithm to ensure his security ; then the actual Web content encryption using symmetric encryption algorithm , the use of symmetric encryption algorithm speed advantage,hash algorithm is mainly to prevent the occurrence of tampering, is a verification mechanism , the final digital certificate, to ensure that the server in the asymmetric encryption algorithm of the public key to the browser when the security (will not be tampered with the middleman), but also the identity of the server.

2) HTTPS four King Kong:

Asymmetric encryption Algorithm (secret key of symmetric encryption algorithm) + symmetric encryption Algorithm (encrypted content) + digital certificate (public key of asymmetric encryption algorithm) + hash Algorithm (prevent tampering) = = HTTPS

The principle of HTTPS (SSL/TLS) in layman