Shulou(Shulou.com)06/03 Report--

Description of blog post [preface]:

This article will introduce TLS, SSL and other related knowledge in a personal tone. At the current time [May 21, 2017], the technical level mastered is limited, and there may be a lot of knowledge that is not in-depth or comprehensive enough. I hope you will point out the problems and communicate with each other. If you find that there is a discrepancy between the content of this article and the actual situation in the follow-up work and study, it will improve the content of this blog.

1. The first bullet: to realize the first bullet of the HTTPS series [introduction to the concept of http,https,www,web]

Link to blog posts: http://watchmen.blog.51cto.com/6091957/1922919

2. Second bullet: implement the second bullet of HTTPS series [introduction to the concepts of asymmetric encryption, public key and private key, digital signature, OpenSSL and HTTPS]

Link to blog posts: http://watchmen.blog.51cto.com/6091957/1923426

3. Third bullet: realize the concept understanding of the third bullet of HTTPS series [digital signature, digital certificate, CA authentication, etc.]

Link to blog posts: http://watchmen.blog.51cto.com/6091957/1924747

References, links and other materials in this article:

1. Https://www.openssl.org/docs/

2. Https://www.feistyduck.com/? [classic, highly recommended, TLS/SSL technical documentation website]

3. Https://www.ssllabs.com [classic, highly recommended, online testing website SSL/TLS security strength]

The website belongs to qualys, qualiy's ssl labs, a cloud security company, www.qualys.com

4. Recommended books: "Bulletproof SSL and TLS"-author Ivan Ristic. I have uploaded the information, which can be searched and downloaded from the site.

Download path: http://down.51cto.com/data/2306452

5. Http://www.techug.com/post/https-ssl-tls.html [required]

6. Http://kb.cnblogs.com/page/197396/

7. Http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html [required]

8. Https://technet.microsoft.com/en-us/library/cc784450(v=ws.10).aspx

Text:

First of all, HTTP is a network protocol that is specifically used to transmit Web content. Even if you don't know about this agreement, at least you've heard of it. For example, if you visit Baidu's home page, the following URL http://www.baidu.com/ will appear in the browser's address bar.

This refers to accessing the content of Baidu's web server through the HTTP protocol. In the early days of Internet development, most websites transmitted Web pages and all kinds of things contained in Web pages (pictures, CSS styles, JS scripts, etc.) through the HTTP protocol. This part of the content can be viewed in my first blog post a simple understanding, okay, the basic knowledge introduction is over, the story begins.

One: what is SSL/TLS? :

SSL (Security Socket Layer, secure socket layer) was designed by Netscape in the mid-1990s. (Netscape not only invented SSL, but also invented a lot of Web infrastructure, such as "CSS style sheet" and "JS script".)

TLS (Transport Layer Security, Transport layer Security Protocol) is the subsequent version of SSL, which develops and optimizes on the basis of SSL.

The main goal of TLS is to make SSL more secure and the specification of the protocol more accurate and perfect, so TLS provides some enhancements on the basis of SSL v3.0 (including safer MAC algorithm, stricter alerts, clearer definition of "grey area" specification, etc.)

TLS allows downgrading the use of SSLv3 when negotiations fail, but due to vulnerabilities, most browsers of manufacturers have disabled this feature. In other words, the mainstream is to use TLS now, but due to historical problems, some servers are still using SSL.

At that time, HTTP communication without SSL/TLS was communication without encryption. All the information is transmitted in clear text, which brings three major risks.

(1) eavesdropping risk (eavesdropping): a third party can know the content of the communication.

(2) tampering risk (tampering): a third party can modify the content of the communication.

(3) impersonating risk (pretending): a third party can participate in communication by pretending to be another person's identity.

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

(1) authenticate users and servers to ensure that data is sent to the correct clients and servers to prevent identity impersonation.

(2) encrypt data to prevent data from being stolen. All information is encrypted and cannot be eavesdropped by third parties.

(3) maintain the integrity of the data, ensure that the data will not be changed in the process of transmission, and have a verification mechanism. Once it is tampered with, both sides of the communication will find it immediately.

What we usually call HTTPS protocol is actually a combination of "HTTP protocol" and "SSL/TLS protocol". You can decompose HTTPS as HTTP over SSL "or" HTTP over TLS ".

It is concluded that 1:SSL/TLS is a network protocol to achieve communication security in the Internet.

Second, the development history of SSL/TLS:

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

In 1995, NetScape released SSL version 2. 0, and soon discovered that there were serious vulnerabilities.

In 1996, SSL 3.0 was published and applied on a large scale.

In 1999, ISOC, an Internet standardization organization, took over from NetScape and released TLS 1.0, an upgraded version of SSL.

In 2006 and 2008, TLS underwent two upgrades, TLS version 1.1 and TLS version 1.2. The latest change is the 2011 revision of TLS 1.2.

At present, TLS 1.2/TLS1.3 is the most widely used, followed by SSL 3.0. At present, mainstream browsers have implemented TLS 1.2 support. For veteran players, TLS 1.0 is usually labeled SSL 3.1 Magi TLS 1.1 as SSL 3.2 Magi TLS 1.2 as SSL 3.3.

Third: brief introduction to the implementation of SSL/TLS protocol?

Application layer (HTTP,SMTP,IMAP) Application layer (HTTP,SMTP,IMAP)

| | |

Presentation layer (SSL,TLS) presentation layer (SSL,TLS)

| | |

Session layer (-)

| | |

Transport layer (TCP,UDP) Transport layer (TCP,UDP)

| | |

Network layer (IP,IPSec) Network layer (IP,IPSec)

| | |

Data Link layer (Ethernet) data Link layer (Ethernet)

| | |

Physical layer (CAT5) physical layer (CAT5)

As we can see from the above, both SSL and TLS work in layer 6, that is, the presentation layer (presentation). In the actual data direction, the number of layers in OSI is logically variable, and can be deleted if it is not needed, so if HTTP needs encryption to implement HTTPS, then we will add the presentation layer, because the HTTP layer is the application layer, which can control the number of layers below. So our data flow at this time is: application layer-- > TLS--- > TCP-- > IP-- > physical layer-- > peer physical layer-- > peer application layer, that is, connect to TCP through TLS. If we just need HTTP, then we abandon the presentation layer, and HTTP sends data directly to TCP, that is, layer 7 to layer 4.

From the above we can simply see that TCP protocol is the cornerstone of HTTP protocol-HTTP protocol needs to rely on TCP protocol to transmit data. Therefore, if you look at the PID corresponding to the encrypted port on the server configured with https, you will find that it is 80 corresponding to the PID, this is because the encryption is based on the hosted http. That is, the data goes to 80, and then 80 to 443443 is wrapped up and passed on.

Summary 2:

1. Considering the compatibility of HTTP (the compatibility here includes many aspects, such as the existing Web applications should be migrated to HTTPS; as seamlessly as possible, for example, for browser vendors, the changes should be as small as possible), so HTTPS still needs to be transferred based on TCP (if it is changed to UDP as the transport layer, both the Web server and browser client will need to be greatly changed)

2. The implementation process is to use a new protocol to wrap the HTTP protocol (the so-called "HTTP over SSL" is actually a layer of SSL encapsulation on top of the original HTTP data. The original GET, POST and other mechanisms of the HTTP protocol are basically intact)

For example, if the original HTTP is a plastic pipe and is easy to be punctured, then the newly designed HTTPS is like a layer of metal pipe in addition to the original plastic pipe. On the one hand, the original plastic pipe still works; second, after being reinforced with metal, it is not easy to be punctured.

Note: as mentioned earlier, HTTPS is the equivalent of "HTTP over SSL", and the design of SSL in terms of "scalability" is strong enough to match not only with HTTP, but also with other application layer protocols. Today's SSL/TLS can be matched with many commonly used application layer protocols (such as FTP, SMTP, POP, Telnet) to enhance the security of these application layer protocols.

One more thing: in fact, both SSL and TLS protocols are made up of two subprotocols.

SSL protocol can be divided into two layers:

SSL recording Protocol (SSL Record Protocol): based on reliable transport protocols (such as TCP), it provides support for high-level protocols such as data encapsulation, compression, encryption and other basic functions.

SSL handshake Protocol (SSL Handshake Protocol): it is based on the SSL recording protocol and is used for identity authentication, negotiation of encryption algorithms, exchange of encryption keys, etc., before the actual data transmission begins.

TLS is also divided into two layers:

TLS recording Protocol (TLS Record): used to encapsulate a variety of high-level protocols. The recording protocol supports information transmission, segmenting data into processable blocks, compressing data, applying MAC, encryption, and transmitting results, etc. The received data is decrypted, verified, decompressed, reassembled, etc., and then transmitted to the high-level client. TLS recording protocol is a layered protocol. The information in each layer may contain fields such as length, description, and content.

TLS handshake Protocol (TLS Handshake): allows the server and client to authenticate each other and negotiate encryption algorithms and encryption keys before the application protocol transmits and receives its first byte of data.

Fourth: SSL/TLS implementation process?

The basic idea of SSL/TLS protocol is to use the public key encryption method, that is to say, the client first requests the public key from the server, then encrypts the information with the public key, and after receiving the ciphertext, the server decrypts it with its own private key.

However, there are two problems.

(1) how to ensure that the public key is not tampered with?

Solution: put the public key in the digital certificate. As long as the certificate is trusted, the public key is trusted.

(2) the computation of public key encryption is too large, how to reduce the time consumed?

Solution: with each conversation (session), the client and server generate a "conversation key" (session key) that is used to encrypt information. Because the "conversation key" is symmetrical encryption, the operation speed is very fast, while the server public key is only used to encrypt the "conversation key" itself, which reduces the time consuming of the encryption operation.

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

(1) the client requests and verifies the public key from the server.

(2) the two parties negotiate to generate a "conversation key".

(3) both parties use "conversation key" to encrypt communication.

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

The detailed process of the handshake stage

The "handshake phase" involves four communications. Let's look at them one by one. It is important to note that all communications in the "handshake phase" are plaintext.

1. Request from the client (ClientHello)

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

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

(1) the version of the protocol supported by the client, such as TLS version 1.0.

(2) A random number generated by a client (the first random number), which is later used to generate a "conversation key".

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

(4) supported compression methods.

It should be noted here that the domain name of the server is not included in the information sent by the client. In other words, in theory, the server can only contain one website, otherwise it will be unclear which website's digital certificate should be provided to the client. This is why there is usually only one digital certificate per server.

For users of virtual hosts, this is of course very inconvenient. In 2006, the TLS protocol added a Server Name Indication extension that allows the client to provide the domain name it requests to the server.

2. Server response (SeverHello)

When the server receives the client request, it sends a response to the client, which is called SeverHello. The server's response contains the following.

(1) confirm the version of the encrypted communication protocol used, such as TLS 1.0. 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 (the second random number), which 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 another request for the client to provide a "client certificate." For example, financial institutions often only allow certified customers to connect to their own network, and then provide USB keys to regular customers, which contains a client certificate.

Note: digital signatures are also involved here, that is, the verification of digital signatures is only used during the handshake of the TLS protocol, and the digital signature is invalid at the end of the handshake.

3. Client response

After the client receives a response from the server, it first verifies the server certificate. 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 will be displayed to the visitor to choose whether or not to continue the communication.

If there is nothing wrong with the certificate, the client removes the server's public key from the certificate. Then, send the following three pieces of information to the server.

(1) A random number (the third random number). The random number is encrypted with the server public key to prevent eavesdropping.

(2) Encoding change notification, indicating that subsequent information will be sent using the encryption method and key agreed upon by both parties.

(3) notice the end of the client handshake, indicating that the handshake phase of the client has ended. This item is also the hash value of all the previously sent content, which is used for verification by the server.

The random number of the first item above is the third random number that appears in the whole handshake stage, also known as "pre-master key". With it, the client and server have three random numbers at the same time, and then the two sides use the agreed encryption method to generate the same "session key" used in this session.

Why must three random numbers be used to generate a "session key"?

Explanation: "Random numbers are required for both the client and the server, so that the generated keys are not always the same. Because the certificate in the SSL protocol is static, it is necessary to introduce a random factor to ensure the randomness of the negotiated key.

For RSA key exchange algorithm, pre-master-key itself is a random number, coupled with the random in hello messages, three random numbers finally derive a symmetric key through a key exporter.

The existence of pre master lies in the fact that SSL does not trust that each host can generate completely random numbers. If the random numbers are not random, then pre master secret may be guessed, so only pre master secret is not suitable as the key, so new random factors must be introduced. Then the key generated by the client and server plus pre master secret random numbers is not easy to be guessed, and a pseudo-random may not be random at all. However, three pseudorandom are very close to random, and for each additional degree of freedom, the randomness increases by not one. "

In addition, if the server requires a client certificate in the previous step, the client will send the certificate and related information at this step.

4. The final response of the server

After receiving the third random number pre-master key from the client, the server calculates the session key used to generate this session. Then, the following information is finally sent to the client.

(1) Encoding change notification, indicating that subsequent information will be sent using the encryption method and key agreed upon by both parties.

(2) the notification of the end of the server handshake indicates that the handshake phase of the server has ended. This item is also the hash value of all the previously sent content, which is used for client verification.

At this point, the whole handshake stage is over. Next, when the client and the server enter encrypted communication, they completely use the normal HTTP protocol, but encrypt the content with a "session key".

Summary 3: the symmetric key used in the actual data transmission is calculated according to the three random numbers generated through negotiation between the two parties.

End:

The next article: realizing the fifth bullet of HTTPS series (final chapter) [realizing HTTPS through OpenSSL]

Blog address: http://watchmen.blog.51cto.com/6091957/1933161

Thank you for reading, have a fruitful day, thank you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.