Overview of the operating mechanism of SSL/TLS protocol

Original address: http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

Internet communication security, based on the SSL/TLS protocol.

This paper briefly introduces the operating mechanism of SSL/TLS protocol. The emphasis of this article is on the design idea and the running process, and does not involve specific implementation details. If you want to know something about this, please refer to the RFC documentation.

First, the role

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.

Second, history

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.

Three, the basic operation process

The basic idea of the SSL/TLS protocol is to use public key cryptography, that is, the client requests the public key to the server, then encrypts the information with the public key, and the server receives the ciphertext and decrypts it with its private key.

However, there are two problems here.

(1) How to ensure that the 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 symmetric encryption, the operation is very fast, and the server public key is used only to encrypt the "conversation key" itself, which reduces the time spent on cryptographic operations.

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

(1) The client requests and validates the public key from the server side.

(2) Both parties negotiate to generate a "dialog key".

(3) The two parties use the "dialogue key" for encrypted communication.

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

Iv. 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.

4.1 Client-issued 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) Supported protocol versions, such as TLS version 1.0.

(2) A random number generated by a client that is later used to generate a "conversation key".

(3) Supported encryption methods, such as RSA public key cryptography.

(4) supported compression methods.

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.

4.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 "conversation key".

(3) Confirm the encryption method used, such as RSA public key encryption.

(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.

4.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 server's public key from the certificate. Then, send the following three messages to the server.

(1) a random number. This random number is encrypted with the server public key to prevent eavesdropping.

(2) The code changes the notification, indicating that the subsequent information will be sent with mutually agreed encryption method and key.

(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 the two parties use the previously agreed encryption method to generate the same "session key" used for this session.

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. "

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

4.4 Final response of the server

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

(1) The Code changes the notification, indicating that the subsequent information will be sent with mutually agreed encryption method 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.

V. 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?

Overview of the operating mechanism of SSL/TLS protocol