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

What this article shares with you is about how to analyze the principle of SSL/TLS. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

1. SSL/TLS Overview 1.1 overall structure

SSL is an optional layer between HTTP protocol and TCP, and its location is roughly as follows:

SSL: (Secure Socket Layer, secure socket layer), developed by Netscape to ensure the security of data transmission over Internet, using data encryption (Encryption) technology to ensure that data will not be intercepted during transmission over the network. The current version is 3.0. It has been widely used in authentication and encrypted data transmission between Web browsers and servers.

SSL protocol is located between TCP/IP protocol and various application layer protocols, which provides security support for data communication. SSL protocol can be divided into two layers: SSL recording Protocol (SSL Record Protocol): it is based on reliable transport protocols (such as TCP) and 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: (Transport Layer Security, transport layer security protocol), used to provide confidentiality and data integrity between two applications.

TLS 1.0 is a new protocol developed by IETF (Internet Engineering Task Force,Internet Engineering Task Force). It is based on the SSL 3.0 protocol specification and is the follow-up version of SSL 3.0.It can be understood as SSL 3.1.It is written into RFC. The protocol consists of two layers: TLS recording Protocol (TLS Record) and TLS handshake Protocol (TLS Handshake). The lower layer is the TLS recording protocol, which sits on top of a reliable transport protocol, such as TCP.

The main services provided by the SSL/TLS protocol are:

Authenticate users and servers to ensure that data is sent to the correct clients and servers

Encrypt data to prevent it from being stolen

Maintain the integrity of the data to ensure that the data will not be changed during transmission.

1.2 differences between TLS and SSL

Version number: the TLS record format is the same as the SSL record format, but the value of the version number is different. Version 1.0 of TLS uses the version number SSLv3.1.

Message authentication code: the MAC algorithm and MAC calculation range of SSLv3.0 and TLS are different. TLS uses the HMAC algorithm defined by RFC-2104. SSLv3.0 uses a similar algorithm, except that in SSLv3.0, a join operation is used between the padding byte and the key, while the HMAC algorithm uses an XOR operation. But the two have the same level of security.

Pseudorandom function: TLS uses a pseudorandom function called PRF to extend the key into blocks, which is a more secure way.

Alarm code: TLS supports almost all SSLv3.0 alarm codes, and TLS also defines a lot of alarm codes, such as decryption failure (decryption_failed), record overflow (record_overflow), unknown CA (unknown_ca), access denied (access_denied) and so on.

Ciphertext family and client certificate: there is a slight difference between SSLv3.0 and TLS, that is, TLS does not support Fortezza key exchange, encryption algorithms, and customer certificates.

Certificate_verify and finished messages: when SSLv3.0 and TLS calculate MD5 and SHA-1 hash codes with certificate_verify and finished messages, the calculated input is slightly different, but the security is equal.

Encrypted calculation: TLS and SSLv3.0 use different ways to calculate the principal secret value (master secret).

Padding: the padding bytes that need to be added before the user data is encrypted. In SSL, the length of the filled data should reach the minimum integer multiple of the ciphertext block length. In TLS, the length of the populated data can be any integer multiple of the ciphertext block length (but the maximum filled length is 255bytes), which can prevent attacks based on the analysis of the message length.

Key enhancements to TLS

The main goal of TLS is to make SSL more secure and to make the specification of the protocol more accurate and perfect. TLS builds on SSL v3.0 and provides the following enhancements:

A more secure MAC algorithm

A tighter alarm

A clearer definition of the "grey area" specification

TLS's improvement on security

Use key hashing for message authentication: TLS uses "key hashing of message authentication codes" (HMAC), which ensures that records are not changed when they are sent over an open network, such as the Internet. SSLv3.0 also provides keyed message authentication, but HMAC is more secure than the (message authentication code) MAC function used by SSLv3.0.

Enhanced pseudorandom function (PRF): PRF generates key data. In TLS, HMAC defines PRF. PRF uses two hashing algorithms to ensure its security. If either algorithm is exposed, as long as the second algorithm is not exposed, the data is still secure.

Improved completed message validation: both TLS and SSLv3.0 provide completed messages to both endpoints, which authenticate that the messages exchanged have not been changed. However, TLS bases this completed message on PRF and HMAC values, which is also more secure than SSLv3.0.

Consistent certificate processing: unlike SSLv3.0, TLS attempts to specify the type of certificate that must be exchanged between TLS.

Specific alert messages: TLS provides more specific and additional alerts to indicate problems detected by any session endpoint. TLS also records when certain alerts should be sent.

two。 Key negotiation process-- TLS handshake

SSL protocol is divided into two parts: Handshake Protocol and Record Protocol. Among them, Handshake Protocol is used to negotiate a key, and most of the content of the protocol is how to use it to negotiate a key securely. Record Protocol defines the format of the transmission.

Because the speed of asymmetric encryption is relatively slow, it is generally used for key exchange. The two parties negotiate a key through the public key algorithm, and then communicate through symmetric encryption. Of course, in order to ensure the integrity of the data, it has to be processed by HMAC before encryption.

By default, SSL only authenticates on the server side, and client authentication is optional. The following is its flow chart (extracted from the TLS protocol).

2.1 request from the client (ClientHello)

Because the client (such as browser) has different support for some encryption and decryption algorithms, but in the process of TLS protocol transmission, the same set of encryption and decryption algorithms must be used to ensure that the data can be encrypted and decrypted normally. In the TLS handshake phase, the client first tells the server which encryption algorithms it supports, so the client needs to send a list of locally supported cryptographic suites (Cipher Suite) to the server. In addition, the client has to generate a random number, which needs to be saved on the client side on the one hand and transmitted to the server on the other hand. The random number on the client side needs to be combined with the random number generated by the server to generate the Master Secret to be discussed later.

To sum up, in this step, the client mainly provides the following information to the server:

Supported protocol versions, such as TLS version 1.0

A random number generated by the client, which is later used to generate a "conversation key"

Supported encryption methods, such as RSA public key encryption

Supported compression methods

2.2 Server response (SeverHello)

In the figure above, from Server Hello to Server Done, some server implementations are sent separately, while some server implementations are merged and sent together. Both Sever Hello and Server Done are data with only headers but no content.

After receiving the Client Hello from the client, the server needs to send its own certificate to the client. This certificate is a kind of authentication for the server. For example, the client receives a piece of data that calls itself www.alipay.com, but how can it prove that the other party is a legitimate alipay Alipay? This is the function of the certificate. Alipay's certificate can prove that it is alipay, not Tenpay. A certificate is an e-certificate that needs to be applied for and issued by a special digital certificate authority (CA) after a very rigorous audit. A private key and a public key are generated when the certificate is issued. The private key is kept by the server itself and cannot be disclosed. The public key is attached to the information of the certificate and can be disclosed. The certificate itself also comes with an electronic signature of the certificate, which is used to verify the integrity and authenticity of the certificate and can prevent the certificate from being tampered with. In addition, the certificate has a validity period.

When the certificate sent by the server to the client does not provide enough information (certificate public key), you can also send a Server Key Exchange to the client.

In addition, for the very important confidential data, the server also needs to verify the client to ensure that the data is transmitted to a secure and legitimate client. The server can send a Cerficate Request message to the client, requiring the client to send a certificate to verify the legitimacy of the client. 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.

Like the client, the server needs to generate a random number to send to the client. Both the client and the server need to use these two random numbers to generate Master Secret.

Finally, the server sends a Server Hello Done message to the client, indicating that the Server Hello message is over.

To sum up, at this step, the server's response consists of the following:

Confirm the version of the encrypted communication protocol you are using, such as TLS 1.0. If the browser does not match the version supported by the server, the server shuts down the encrypted communication

A random number generated by a server, which is later used to generate a "conversation key"

Confirm the encryption method used, such as RSA public key encryption

Server certificate

2.3 client response (Certificate Verify)

Client Key Exchange

If the server needs to verify the client, after the client receives the Server Hello message from the server, it first needs to send the client's certificate to the server and let the server verify the legitimacy of the client.

Certificate Verify

Next, the client needs to check the certificate of the server. If the certificate is not issued by a trusted institution, or if the domain name in the certificate is inconsistent with the actual domain name, or if the certificate has expired, it will display a warning to the visitor. It is up to them to choose whether to continue to communicate. If there is no problem with the certificate, the client removes the server's public key from the server certificate. Then, send the following three messages to the server:

A random number. The random number is encrypted with the server public key to prevent eavesdropping.

Notification of code change, indicating that subsequent information will be sent using the mutually agreed encryption method and key

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

The random number in the first item above is the third random number that appears throughout the handshake phase. It is the client that uses some encryption algorithms (for example: RSA, Diffie-Hellman) to generate a 48-byte Key called PreMaster Secret, which is also called PreMaster Key in many materials.

ChangeCipherSpec

ChangeCipherSpec is an independent protocol, reflected in the packet is a byte of data, used to inform the server that the client has switched to the previously negotiated encryption suite (Cipher Suite) state, ready to use the previously negotiated encryption suite to encrypt the data and transfer.

After the ChangecipherSpec transmission is completed, the client will use the previously negotiated cipher suite and Session Secret to encrypt a piece of Finish data to the server to verify the encryption and decryption channel established by the handshake before formally transmitting the application data.

2.4 final response from the server (Server Finish)

After receiving the PreMaster encrypted data from the client, the server uses the private key to decrypt the encrypted data and validates the data, and generates Session Secret in the same way as the client. When everything is ready, it will send a ChangeCipherSpec to the client, informing the client that it has switched to the negotiated cipher suite state and is ready to use the cipher suite and Session Secret to encrypt the data. After that, the server also uses Session Secret to encrypt a Finish message to the client to verify the success of the encryption and decryption channel established by the handshake.

According to the previous handshake information, if both the client and the server can encrypt and decrypt the Finish information normally and the message is verified correctly, the handshake channel has been established successfully, and then both parties can use the Session Secret generated above to encrypt and transmit the data.

More than 2.5 secret

Secret Keys

The above analysis and explanation is mainly to highlight the handshake process, so PreMaster secret,Master secret,session secret is a generation, but for in-depth understanding and mastery of Https,SSL/TLS, these Secret Keys is a very important part. Therefore, we are going to extract these Secret Keys for separate analysis and explanation.

Let's first take a look at the generation process and flow chart of these Secret Keys:

PreMaster secret

PreMaster Secret is generated on the client using encryption algorithms such as RSA or Diffie-Hellman. It will be used to generate Master Secret together with the random numbers generated by the server and the client during the Hello phase. After the client encrypts the PreMaster Secret with the public key of the server, the server sends it to the server, and the server will decrypt the PreMaster secret with the private key. In other words, both the server and the client have the same PreMaster secret and random number.

The first two bytes of PreMaster secret are the version number of TLS, which is an important version number used to check handshake data, because in the Client Hello phase, the client will send a list of cryptographic suites and the version number of the currently supported SSL/TLS to the server, and it is sent in clear text. If the handshake packet is cracked, the attacker is likely to tamper with the packet. Select a less secure encryption suite and version to the server to crack the data. Therefore, the server needs to compare the PreMaster version number of the decrypted pair in the ciphertext with the version number of the previous Client Hello phase. If the version number becomes lower, it indicates that it has been changed in series, and then immediately stops sending any messages.

For the calculation of PreMaster Secret (Key), please refer to Https SSL/TLS PreMaster/Master Secret (Key) calculation.

Master secret

As mentioned above, since both the server and the client have the same PreMaster secret and random number, this random number will be used as the seed for later generation of Master secret. Combined with PreMaster secret, the client and server will calculate the same Master secret.

Master secret consists of a series of hash values that will be part of the Key Material of the secret associated with data encryption and decryption. The final data parsed by Key Material is as follows:

Among them, write MAC key is session secret or session key. Client write MAC key is the session secret,Server write MAC secret that the client sends data, and the session key that the server sends data. MAC (Message Authentication Code) is a digital signature that is used to verify the integrity of the data and can detect whether the data has been tampered with.

For the calculation of Session Secret (Key), please refer to Https SSL/TLS Session Secret (Key) calculation.

2.6 Application data transmission

After all the handshake phases are complete, you can begin to transfer application data. Before the application data is transmitted, the MAC secret must be attached first, and then the packet is encrypted using write encryption key. After receiving the ciphertext, the server uses Client write encryption key for decryption, the client receives the data of the server, decrypts it using Server write encryption key, and then uses their own write MAC key to verify the integrity of the data, including whether it has been tampered with.

2.7 Summary

After the TCP link is established, the SSL client (also the client of TCP) sends out a ClientHello to initiate the handshake, which contains a list of algorithms that can be implemented and other necessary messages. The server of SSL will respond to a ServerHello, which determines the algorithm needed for this communication, and then sends its own certificate (which contains identity and public key). After receiving this message, Client will generate a secret message, encrypt it with the public key of the SSL server and pass it over. After the SSL server decrypts it with its own private key, the session key negotiation is successful, and the two parties can communicate with the same session key.

3. Attached: the visual metaphor of key negotiation

If the above description is not clear enough, let's use a visual analogy here. Let's assume that A communicates with B, An is the SSL client, and B is the SSL server, and the encrypted message is placed in square brackets [] to highlight the difference between plaintext messages. The description of the handling actions of both parties is enclosed in parentheses ().

A: I'd like to talk to you securely. The symmetric encryption algorithms I have here are DES,RC5, the key exchange algorithms are RSA and DH, and the summary algorithms are MD5 and SHA.

B: let's combine this pair with DES-RSA-SHA.

This is my certificate with my name and public key in it. You can verify my identity (send the certificate to A).

There is nothing else to say at the moment.

A: (check whether the name of B on the certificate is correct, and verify the authenticity of B's certificate through the CA certificate on hand. If one of the items is wrong, issue a warning and disconnect. This step ensures the authenticity of B's public key.)

Generate a secret message that, after processing, will be used as an encryption key to encrypt the initialization vector (IV) and the key of hmac. This secret message, called per_master_secret- in the protocol, is encrypted with the public key of B and encapsulated into a message called ClientKeyExchange. Due to the use of B's public key, it is guaranteed that third parties cannot eavesdrop)

I generated a secret message, encrypted it with your public key, and gave it to you (send ClientKeyExchange to B)

Attention, I'm going to use encryption to send you a message!

(process secret messages, generate encryption keys, encrypt initialization vectors and keys for hmac)

[I'm done]

B: (decrypt the secret message in ClientKeyExchange with your own private key, then process the secret message, generate the encryption key, encrypt the initialization vector and the key of hmac, and then the two parties have safely negotiated a set of encryption methods.)

Attention, I'm going to start sending you encrypted messages, too!

[I'm done]

My secret is...]

B: no one else will hear it.]

4. SSL security

The article "The End of SSL and SSH?" written by SecurityPortal at the end of 2000 has aroused a lot of discussion. At present, there are also some mature tools such as dsniff (http://www.monkey.org/~dugsong/dsniff/) that can intercept https messages through man in the middle attacks.

From the above principle, we can see that the structure of SSL is rigorous, and the problems generally appear in the practical applications that are not rigorous. The common attack is middle in the middle attack, which means that while An and B communicate, there is a third party C in the middle of the channel, and the messages of An and B communication can be heard completely, and these messages can be intercepted, replaced and added.

SSL can allow a variety of key exchange algorithms, while some algorithms, such as DH, do not have the concept of certificate, so A can not verify the authenticity of B's public key and identity, so C can easily pretend to use its own key to communicate with both parties, thus eavesdropping on other people's conversation.

In order to prevent middle in the middle attacks, a certified key exchange algorithm should be used.

After having a certificate, if C replaces the original certificate with its own certificate, A's browser will pop up a warning box to warn you, but how many people will pay attention to this warning?

Due to the restrictions on the export of passwords in the United States, the encryption strength supported by browsers such as IE,netscape is very weak, and it is theoretically possible to crack if only the encryption function of the browser is used.

5. Agent

Let's explore how the SSL agent works.

When a proxy for https is set in the browser and https://www.example.com is entered in the browser, the browser establishes a tcp link with proxy and sends it a message like this:

CONNECT server.example.com:443 HTTP/1.1Host: server.example.com:443

Proxy then establishes an tcp connection to the webserver side, after which the agent becomes a complete content forwarding device. The browser and web server will establish a secure channel, so this secure channel is end-to-end. Although all the information flows through the proxy, its content proxy cannot be decrypted and changed (of course, it must be supported by the certificate, otherwise this place is a good place for man in the middle attacks, see the security section above).

CA certificate and how to use OpenSSL self-signed, see the article OpenSSL self-signed certificate.

The above is how to analyze the principle of SSL/TLS. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.