How SSL Works

How SSL Works

http://blog.csdn.net/it_man/article/details/24698093

Public and private keys

All along the public and private keys have not been understood very thoroughly, feeling ambiguous. Today on the internet for half a day, by looking at the understanding of this key pair, finally figured out.       public and private keys are commonly known as asymmetric encryption, which is improved from the previous symmetric encryption (using user name and password). Explain the principle in e-mail.       The purpose of using public and private keys is to implement secure e-mail, which must be done for the following purposes:       1. The content I send to you must be encrypted and cannot be seen by others during the transmission of the message.       2. I must be sure that I sent the mail, not someone impersonating me.       to achieve such a goal, both people who have to send mail have public and private keys.       public key, is for everyone to use, you can publish by e-mail, can be downloaded through the website, the public key is actually used to encrypt/stamp use. The private key, is his own, must be very careful to save, preferably with a password, the private key is used to decrypt/seal, first of all the key ownership, the private key only personal ownership. The function of public key and private key is: the content encrypted with public key can only be decrypted with private key, and the content encrypted with private key can only be decrypted with public key.       For example, I'm going to send you an encrypted message. First, I have to have your public key, and you have to have my public key.       first of all, I use your public key to encrypt this message, so that the message is not seen by others, and ensure that the message is not modified during the transfer process. After you receive the email, you can decrypt it with your private key and you can see the content.       Next I use my private key to encrypt this message, and after sending it to your hand, you can decrypt it with my public key. Because the private key is only in my hand, this ensures that this email is sent to me.       when a->b data, a will use B's public key encryption, so as to ensure that only B can unlock, otherwise the general public can unlock the encrypted message, is to the confidentiality of information. Verification aspect is the use of the mechanism of the signing of the seal, a transmission of information to everyone, will be the signature of their own private key, so that all the people who receive the message can use A's publicKey to verify that the message was sent by a.

The principle of digital certificate

The digital certificate adopts the public key system, which uses a pair of matching keys to encrypt and decrypt. Each user sets a specific private key (private key) that is only known to me, decrypts and signs it, and sets a public key (public key) to be shared with a group of users to encrypt and verify the signature. When a confidential file is sent, the sender encrypts the data with the receiver's public key, and the receiver decrypts it with its own private key, so that the information can arrive at the destination safely and without error. The encryption process is ensured by means of a digital process, that is, only the private key can be decrypted. In the public key cryptosystem, the RSA system is commonly used. The user can also use their own private key to the information processing, because the key is only for me, so that the others can not generate files, also formed a digital signature. Using digital signature, can confirm the following two points: (1) The guarantee information is sent by the signer's own signature, the signer can not be denied or difficult to deny, (2) to ensure that the information has not been issued until the receipt of any changes, issued documents are real documents.

SSL is a security protocol that provides privacy and integrity between communication applications that use TCP/IP. The Hypertext Transfer Protocol (HTTP) of the Internet uses SSL for secure communication.

The data that is transferred between the client and the server is encrypted by using a symmetric algorithm such as DES or RC4. The public key algorithm (usually RSA) is used to obtain encryption key exchange and digital signature, which uses the public key in the server's SSL digital certificate. With the SSL digital certificate of the server, the client can also verify the identity of the server. Versions 1 and 2 of the SSL protocol only provide server authentication. Version 3 adds client authentication, which requires both client and server digital certificates.

SSL Handshake/

SSL connections are always initiated by the client. The SSL handshake is performed at the beginning of the SSL session. This handshake generates the password parameters for the session. A simple overview of how to handle an SSL handshake, as shown in. This example assumes that an SSL connection has been established between the Web browser and the Web server.

(1) The client sends a client "Hello" message (sorted in the order of client preference items) that lists the client's password capabilities, such as the version of SSL, the password pair supported by the client, and the data compression method supported by the client. The message also contains a random number of 28 bytes.

(2) The server responds with a "hello" message from the server, which contains the password method (password pair) and the data compression method selected by the server, as well as the session ID and another random number.

Note: The client and server must support at least one public password pair, otherwise the handshake fails. The server generally chooses the largest public password pair.

(3) The server sends its SSL digital certificate. (The server uses the V3 digital certificate with SSL.) ）

If the server uses SSL V3, and the server application (such as a WEB server) requires a digital certificate for client authentication, the client issues a "digital certificate request" message. In the digital certificate request message, the server issues a list of supported client digital certificate types and the name of an acceptable CA.

(4) The server issues the server "Hello complete" message and waits for the client to respond.

(5) A client (Web browser) verifies the validity of the server's SSL digital certificate and checks to see if the server's "Hello" message parameters are acceptable when the server "Hello complete" message is received.

If the server requests a client digital certificate, the client sends its digital certificate, or if no appropriate digital certificate is available, the client sends a "No digital certificate" warning. This warning is only a warning, but if the client digital certificate authentication is mandatory, the server application will fail the session.

(6) The client sends a "client key exchange" message.

This message contains pre-master secret (a random number of 46 bytes used in symmetric cryptographic key generation), and a Message authentication code (MAC) key (encrypted with the server's public key).

If the client sends a client digital certificate to the server, the client issues a "digital certificate verification" message that is signed with the client's private key. By verifying the signature of this message, the server can display ownership of the authentication Client digital certificate.

Note: If the server does not have a private key that is part of a digital certificate, it will not be able to decrypt the pre-master password or create the correct key for the symmetric cryptographic algorithm, and the handshake will fail.

(7) The client uses a series of cryptographic operations to convert the Pre-master secret to master secret, which will derive all the keys used for encryption and message authentication. The client then issues a "Change Password specification" message to convert the server to a newly negotiated password pair. The next message sent by the client (the "unfinished" message) is the first message encrypted with this password method and key.

(8) The server responds with its own "Change Password Specification" and "completed" message.

(9) The SSL handshake ends and the encrypted application data can be sent.

SSL Uni-directional authentication

One-way authentication: The client sends a message to the server, the server receives the message, encrypts the data with the private key in the server-side KeyStore, and then sends the encrypted data and the server-side public key to the client, and the client decrypts the data with the public key sent by the server. Then in the server to the client's public key to the data encryption to the server side, the server with the private key to decrypt the data, which completes the client and server communication between the security issues, but one-way authentication does not verify the legitimacy of the client.

Two-way authentication: The client sends a message to the server, first encrypts the message with the client certificate and then sends the client certificate together to the server side, the server receives the message, decrypts the message with the client certificate first, then encrypts the message with the server private key, and sends the server certificate and the message to the client. The client decrypts the message with the server certificate sent, then encrypts the message with the server's certificate, then encrypts the message with the client's certificate, sends it to the server side together with the encrypted message and the client certificate, and decrypts the message to the server using the certificate from the client. Make sure that the message is sent by the client, and then decrypt the message with the server-side private key to get the plaintext data.

Key words: Ssl,pki,mac

Abstract: SSL leverages data encryption, authentication, and message integrity validation mechanisms to provide security assurances for application-layer protocols based on reliable connections such as TCP. This paper introduces the background, security mechanism, working process and typical networking application of SSL.

Abbreviations:

Abbreviations	English full Name	Chinese explanation
Aes	Advanced Encryption Standard	Advanced Encryption Standard
Ca	Certificate Authority	Certificate Authority
Des	Data Encryption Standard	Data Encryption Standard
HTTPS	Hypertext Transfer Protocol Secure	Secure Hypertext Transfer Protocol
Mac	Message Authentication Code	Message Verification Code
MD5	Message Digest 5	Message Digest Algorithm 5
Pki	Public Key Infrastructure	Public Key Infrastructure
Rsa	Rivest Shamir and Adleman	A kind of asymmetric key algorithm
SHA	Secure Hash algorithm	Secure Hashing algorithm
Ssl	Secure Sockets Layer	Secure Sockets Layer
Vpn	Virtual Private Network	Virtual Private Network

1 Overview 1.1 Creating a background

Web-based e-commerce and online banking and other emerging applications, greatly facilitate people's daily life, by People's favor. Because these applications require online transactions on the network, they make higher demands on the security of network communication. The traditional Web protocol HTTP does not have security mechanism--transmitting data in plaintext, unable to verify the identity of both sides of the communication, preventing data from being tampered with, and so on, which makes HTTP unable to meet the security requirements of e-commerce and internet banking applications.

Netscape security protocol SSL, which uses data encryption, authentication and message integrity verification mechanism, provides security for the transmission of data on the network. SSL provides a secure connection to HTTP, which can greatly improve the security of the World Wide Web.

1.2 Technical Advantages

SSL has the following advantages:

L provide high security guarantee. SSL utilizes data encryption, authentication and message integrity verification mechanisms to ensure the security of data transmission on the network.

L support various application layer protocols. Although SSL is designed to address the World Wide Web security issue, SSL is located between the application layer and the transport layer, which provides security assurances for any application-layer protocol based on reliable connections such as TCP.

Deployment is simple. Currently SSL has become a global standard for authenticating Web sites and web browser identities, encrypting communications between users of browsers and Web servers. The SSL protocol has been integrated into most browsers, such as IE, Netscape, Firefox, and so on. This means that almost any computer with a browser can support SSL connections, without the need to install additional client software.

2 Protocol security Mechanisms

The security mechanisms implemented by the SSL protocol include:

l Confidentiality of data transmission: Using symmetric key algorithm to encrypt transmitted data.

L Authentication mechanism: Based on certificates, the server and client are authenticated using the digital signature method, where authentication of the client is optional.

L Message Integrity Verification: The MAC algorithm is used during message transfer to verify the integrity of the message.

2.1 Confidentiality of data transfer

The data transmitted on the network is easily stolen by illegal users, and SSL uses the method of establishing an encrypted channel between the two parties to ensure the confidentiality of data transmission.

The so-called encrypted channel, refers to the sender before sending the data, using encryption algorithm and encryption key to encrypt the data, and then send the data to the other side, the receiver receives the data, the decryption algorithm and encryption key from the ciphertext to obtain clear text. A third party without a decryption key cannot restore ciphertext to plaintext, thus guaranteeing the confidentiality of the data transfer.

The encryption and decryption algorithms are divided into two categories:

L symmetric key algorithm: The same key is used when encrypting and decrypting data.

L Asymmetric key algorithm: Data encryption and decryption using a different key, one is the public public key, one is the secret of the user to save the private key. Data encrypted with a public key (or private key) can only be decrypted with the corresponding private key (or public key).

Compared with asymmetric key algorithm, symmetric key algorithm has the advantage of high computational speed, which is usually used to encrypt a large amount of information (such as encrypting all messages), and the asymmetric key algorithm is generally used for digital signature and less information encryption.

Data encryption on the SSL encryption channel using symmetric key algorithm, currently the main support algorithms are DES, 3DES, AES, etc., these algorithms can effectively prevent the interaction data eavesdropping.

The symmetric key algorithm requires that the decryption key and the encryption key are exactly the same. Therefore, it is necessary to deploy the same key on both sides of the communication before encrypting the transmitted data with the symmetric key algorithm. The method of deploying symmetric keys is described in the 2.4 using asymmetric key algorithms to secure the key itself.

2.2 Authentication mechanism

In applications such as e-commerce and online banking, it is important to ensure that the Web server to be logged in is real, so that critical information is not stolen illegally. SSL uses digital signatures to verify the identity of the communication peer.

Asymmetric key algorithms can be used to implement digital signatures. Since the data encrypted by the private key can only be decrypted with the corresponding public key, the sender's identity can be judged according to the success of the decryption, as if the sender had "signed" the data. For example, Alice uses her private key to encrypt a fixed piece of information and sends Bob,bob to decrypt it using Alice's public key, and if the decryption result is the same as the fixed information, then it is able to confirm that the sender of the message is Alice, a process known as a digital signature.

The SSL client must verify the identity of the SSL server and whether the SSL server verifies the identity of the SSL client, as determined by the SSL server. For the authentication process for SSL clients and SSL servers, see the 3.2 SSL handshake process.

When authenticating with a digital signature, you need to ensure that the public key of the authenticator is true, otherwise the illegal user may impersonate the authenticator to communicate with the authenticator. As shown in 1, Cindy impersonating Bob, sending his public key to Alice and using her private key to calculate the signature sent to Alice,alice to successfully validate the signature using "Bob" 's Public key (which is actually Cindy's public key), Alice considers Bob's authentication successful, What actually communicates with Alice is the Cindy that pretends to be Bob. SSL uses the mechanism provided by the PKI to ensure the authenticity of the public key, in detail see "2.5 using PKI to ensure the authenticity of public key."

Figure 1 Forging the public key

2.3 Message Integrity Verification

To avoid unauthorized tampering of data transmitted over the network, SSL uses a Mac algorithm based on MD5 or SHA to guarantee the integrity of the message.

Mac algorithm is a data digest algorithm under the participation of key, which can convert the key and any length data into fixed length data. The process of verifying message integrity using the MAC algorithm is shown in procedure 2. The sender, with the participation of the key, calculates the Mac value of the message using the MAC algorithm and sends it to the receiver after the message is added. The receiver calculates the MAC value of the message using the same key and Mac algorithm, and compares it to the Mac value received. If the two are the same, the message does not change, otherwise the message is modified during transmission and the receiver discards the message.

Figure 2 Mac algorithm

The MAC algorithm has the following characteristics that enable it to verify the integrity of the message:

Any change in the message will cause a change in the fixed-length data of the output. By comparing Mac values, you can guarantee that the recipient will be able to discover the change in the message.

The MAC algorithm requires the participation of the key, so an illegal user without a key cannot add the correct Mac value after changing the contents of the message, thus ensuring that the message content cannot be modified arbitrarily by the illegal user.

MAC algorithms require that both parties have the same key, otherwise the MAC value verification will fail. Therefore, before verifying message integrity with the MAC algorithm, you need to deploy the same key on both sides of the communication. The deployment method for Mac Keys is described in the 2.4 using an asymmetric key algorithm to secure the key itself.

2.4 Using asymmetric key algorithm to ensure the security of the key itself

Symmetric key algorithms and Mac algorithms require that both parties have the same key, otherwise decryption or Mac value validation will fail. Therefore, to establish an encrypted channel or to verify message integrity, you must first deploy a consistent key on both sides of the communication.

SSL uses an asymmetric key algorithm encryption key method to implement key exchange, to ensure that the third party cannot obtain the key. As shown in 3, SSL clients (such as Web browsers) use the public key encryption key of an SSL server (such as a Web server) to send the encrypted key to the SSL server, and only the SSL server with the corresponding private key can obtain the original key from the ciphertext. SSL usually uses the RSA algorithm to encrypt the transfer key.

Figure 3 Key Exchange

In fact, the key that the SSL client sends to the SSL server cannot be used directly to encrypt the data or calculate the Mac value, which is the information used to compute the symmetric key and the Mac key, called Premaster secret. The SSL client and SSL server use Premaster secret to compute the same master key (master secret), and then use master secret to generate keys for symmetric key algorithms, Mac algorithms, and so on. Premaster secret is the key to compute the key of symmetric key and Mac algorithm.

The algorithm used to implement the key exchange is called the key exchange algorithm. When RSA is used for key exchange, the asymmetric key algorithm can also be called a key exchange algorithm.

Before an asymmetric key algorithm is used to encrypt the key, the sender needs to obtain the recipient's public key and ensure that the public key is indeed the recipient, otherwise the key may be stolen by the illegal user. As shown in 1, Cindy posing as Bob, sending his public key to Alice,alice using Cindy's public key to encrypt the data sent to Bob, Bob, since no corresponding private key could decrypt the data, and Cindy intercepted the data, it could be decrypted with its private key. SSL uses the mechanism provided by the PKI to ensure the authenticity of the public key, in detail see "2.5 using PKI to ensure the authenticity of public key."

2.5 Using PKI to guarantee the authenticity of public key

PKI publishes a user's public key through a digital certificate and provides a mechanism to verify the authenticity of the public key. A digital certificate (certificate) is a file containing the user's public key and its identity, which proves the user's association with the public key. The digital certificate is issued by the Authority--CA and the CA guarantees the authenticity of the digital certificate.

Before the SSL client passes the key encryption to the SSL server, the SSL server needs to send the certificate obtained from the CA to the SSL client, and the SSL client determines the authenticity of the certificate through the PKI. If the certificate does belong to an SSL server, it is sent to the SSL server using the public key encryption key in the certificate.

Before verifying the identity of the SSL server/ssl client, the SSL server/ssl client needs to send the certificate obtained from the CA to the peer-to-peer to determine the authenticity of the certificate through the PKI. If the certificate does belong to the SSL server/ssl client, the peer uses the public key in the certificate to verify the identity of the SSL server/ssl client.

3 Protocol Work Process 3.1 SSL hierarchy

Figure 4 SSL Protocol tiering

As shown in 4, SSL is located between the application layer and the transport layer, which provides security assurances for any application-layer protocol based on reliable connections such as TCP. The SSL protocol itself is divided into two tiers:

L upper layer for SSL handshake Protocol (SSL Handshake Protocol), SSL Password Change protocol (SSL cipher Spec protocol) and SSL warning Protocol (SSL alert Protocol);

The bottom layer is the SSL recording Protocol (SSL record Protocol).

which

L SSL Handshake Protocol: is an important part of the SSL protocol, used to negotiate the encryption suite used in the communication process (encryption algorithm, key exchange algorithm and MAC algorithm, etc.), between the server and the client to securely exchange keys, to implement server and client authentication.

L SSL Password Change protocol: the client and server are notified to the peer via a password change protocol, and subsequent messages will be protected and transmitted using the newly negotiated cryptographic suite and key.

L SSL Warning Protocol: Used to report the alarm information to the communication peer, the message contains the severity level and description of the alarm.

L SSL Logging Protocol: mainly responsible for the upper layer of data (SSL handshake protocol, SSL Password change protocol, SSL warning Protocol and Application layer protocol message) to block, calculate and add Mac values, encryption, and the processing of the record block transmission to the peer.

3.2 SSL Handshake process

SSL negotiates the session parameters between the client and the server through the handshake process and establishes the session. The main parameters that the session contains are the session ID, the other's certificate, the cryptographic suite (key exchange algorithm, data encryption algorithm, MAC algorithm, etc.), and the master key (master secret). Data transmitted over an SSL session will be encrypted using the session's master key and encryption suite, and processing of the MAC is calculated.

In different cases, there are differences in the SSL handshake process. The following three scenarios describe the handshake process, respectively:

Verify the SSL handshake process for the server only

Verify the SSL handshake process for the server and client

• Restore the SSL handshake process for the original session

3.2.1 Verify the SSL handshake process for the server only

Figure 5 Verifying the SSL handshake process for the server only

5, the SSL handshake process is only required to verify the SSL server identity and not to verify the SSL client identity:

(1) The SSL client sends its supported SSL version, encryption algorithm, key exchange algorithm, MAC algorithm and other information to the SSL server via client Hello message.

(2) The SSL server determines the SSL version and encryption suite that this communication uses and notifies the SSL client via the server Hello message. If the SSL server allows the SSL client to reuse this session in future communications, the SSL server assigns the session ID to the session and sends it to the SSL client via the server Hello message.

(3) The SSL server sends the digital certificate with its own public key information to the SSL client via the certificate message.

(4) The SSL server sends the server Hello done message, notifies the SSL client version and the cryptographic suite negotiation ends and begins the key exchange.

(5) The SSL client verifies that the SSL server's certificate is valid, encrypts the SSL client's randomly generated premaster secret with the public key in the certificate, and sends it to the SSL server via client key exchange messages.

(6) The SSL client sends a change CIPHER spec message notifying the SSL server that subsequent messages will be encrypted and Mac computed using a negotiated key and encryption suite.

(7) The SSL client computes the hash value of the interactive handshake message (except for all interactive messages outside the Change Cipher spec message), processes the hash value with the negotiated key and cipher suite (calculates and adds Mac values, encryption, etc.). and sent to the SSL server via finished messages. The SSL server computes the hash value of the interactive handshake message using the same method, and compares it with the decryption result of the finished message, and if the two are the same and the Mac value is validated successfully, the key and cryptographic suite are successfully negotiated.

(8) Similarly, the SSL server sends a change CIPHER spec message notifying the SSL client that subsequent messages will be encrypted and Mac computed using a negotiated key and encryption suite.

(9) The SSL server computes the hash value of the interactive handshake message, processes the hash value with the negotiated key and cipher suite (calculates and adds Mac values, encryption, etc.) and sends it to the SSL client via the finished message. The SSL client uses the same method to calculate the hash value of the interactive handshake message and compares it with the decryption result of the finished message, and if the two are the same and the Mac value is validated successfully, the key and cryptographic suite are successfully negotiated.

After the SSL client receives the finished message sent by the SSL server, if the decryption succeeds, it can be judged that the SSL server is the owner of the digital certificate, the SSL server authentication succeeds, because only the SSL server with the private key can The Premaster secret is decrypted in exchange messages, which indirectly enables the SSL client to authenticate to the SSL server.

& Description:

L The Change Cipher spec message belongs to the SSL password changing protocol, and the messages that interact with other handshake processes are SSL handshake protocols, collectively known as SSL handshake messages.

L calculates the hash value by using a hash algorithm (MD5 or SHA) to convert any length of data into fixed-length data.

3.2.2 Verifying the SSL handshake process between the server and the client

Figure 6 Verifying the SSL handshake process for the server and client

Authentication of the SSL client is optional and is determined by the SSL server to verify the identity of the SSL client. 6 The blue part identifies the content as shown, if the SSL server authenticates the SSL client, the SSL server and SSL client, in addition to interacting with the message negotiation key and encryption suite in the "3.2.1 authentication Server SSL handshake process", also need to do the following:

(1) The SSL server sends a certificate Request message requesting the SSL client to send its certificate to the SSL server.

(2) The SSL client sends the certificate with its own public key to the SSL server via the certificate message. The SSL server verifies the legality of the certificate.

(3) The SSL client computes the interactive handshake message, the hash value of the master key, encrypts it with its own private key, and sends it to the SSL server via the certificate Verify message.

(4) The SSL server calculates the interactive handshake message, the hash value of the master key, decrypts the certificate verify message with the public key in the SSL client certificate, and compares the decryption result with the computed hash value. If the two are the same, SSL client authentication succeeds.

3.2.3 Restore the SSL handshake process for the original session

Figure 7 Recovering the SSL handshake process for an existing session

In the process of negotiating session parameters and establishing a session, it is necessary to use asymmetric key algorithm to encrypt the key, verify the identity of the communication to the end, calculate a large amount, and occupy a large amount of system resources. To simplify the SSL handshake process, SSL allows you to reuse a session that has already been negotiated, as follows:

(1) SSL clients send client Hello messages, and the session ID in the message is set to the ID of the session that is scheduled for reuse.

(2) If the SSL server allows the session to be reused, it is answered by setting the same session ID in the server Hello message. This allows the SSL client and SSL server to take advantage of the original session's key and encryption suite without renegotiation.

(3) The SSL client sends the change CIPHER spec message, notifying the SSL server that subsequent messages will be encrypted and Mac computed using the original session's key and encryption suite.

(4) The SSL client computes the hash value of the interactive handshake message, processes the hash value using the original session's key and cryptographic suite, and sends the finished message to the SSL server so that the SSL server can determine if the key and cryptographic suite are correct.

(5) Similarly, the SSL server sends a change CIPHER spec message notifying the SSL client that subsequent messages will be encrypted and Mac computed using the original session's key and encryption suite.

(6) The SSL server computes the hash value of the interactive handshake message, processes the hash value using the original session's key and cipher suite, and sends the finished message to the SSL client so that the SSL client can determine if the key and cryptographic suite are correct.

4 Typical networking Applications 4.1 HTTPS

HTTPS is an SSL secure connection-based HTTP protocol. HTTPS provides security mechanisms such as data encryption, authentication and message integrity verification through SSL, which provides security for Web Access and is widely used in internet banking, e-commerce and other fields.

The application of HTTPS in Internet banking is shown in Figure 8. In order to facilitate customers, a bank provides online banking services, customers can access the bank's Web server for account inquiries, transfer and so on. By establishing an SSL connection between the customer and the bank's Web server, the customer's information is not illegally stolen.

Figure 8 Application of HTTPS in Internet banking

4.2 SSL VPN

SSL VPN is an SSL-based VPN technology that provides security for users to access the company's internal network remotely, using the security mechanisms provided by SSL. 9, SSL VPN provides a secure SSL connection between the remote access user and the SSL VPN gateway, allowing users to access the enterprise network resources remotely from anywhere through various web browsers, various network access methods, and to ensure the security of the enterprise network and protect the internal information from being stolen.

Figure 9 Typical networking environment for SSL VPN

How SSL Works