How SSL Works

Source: Internet
Author: User
Tags ssl connection

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


Directory

1 Overview ... 3

1.1 Creating the background ... 3

1.2 Technical Advantages ... 3

2 Protocol security mechanism ... 3

2.1 Confidentiality of transmitted data ... 4

2.2 Authentication mechanism ... 4

2.3 Message Integrity Verification ... 5

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

2.5 Using PKI to guarantee the authenticity of public key ... 7

3 protocol work Process ... 8

3.1 SSL hierarchy ... 8

3.2 SSL Handshake process ... 8

3.2.1 Only verifies the server's SSL handshake process ... 9

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

3.2.3 Restore the original session of the SSL handshake process ... A

4 Typical networking applications ... -

4.1 HTTPS. -

4.2 SSL VPN. -

5 references ... -


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--data transmission in plaintext, unable to verify the identity of the two sides of the communication, unable to prevent the data from being tampered with, and so on, the HTTP cannot meet the security requirements of the 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 advantages such as the following:

L provide high security guarantee. SSL leverages data encryption, authentication, and message integrity verification mechanisms to ensure the security of data transmitted over 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 that is based on reliable connections such as TCP.

Deployment is simple. Now SSL has become a global standard used to identify sites and web browser identities in the network, and to encrypt communications between users of browsers and webserver. The SSL protocol has been integrated into most browsers, such as IE, Netscape, Firefox, and so on. This means that an almost random 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:

• Confidentiality of transmitted data: the data transmitted is encrypted using the symmetric key algorithm.

L Authentication mechanism: Based on certificates, the server and client are authenticated using the digital signature method, in which client authentication 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 transmitted data

Data transmitted on the network is very easy to be stolen by illegal users, SSL is used in communication between the two parties to establish an encrypted channel 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 transmitted data.

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 fast computing speed, and it is often used to encrypt large amount of information (such as encrypt all messages), while asymmetric key algorithm is generally used for digital signature and to encrypt less information.

Data encryption on the SSL encryption channel using symmetric key algorithm, the main supported 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 fully consistent. Therefore, it is necessary to deploy the same key on both sides of the communication before encrypting the data transfer with the symmetric key algorithm. How to deploy symmetric keys see "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 necessary to ensure that the webserver to be logged in is real, so that important 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 encrypted data via the private key can only be decrypted with the corresponding public key, it is possible to infer the sender's identity based on 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, assuming that the decryption results are the same as fixed information, and that the sender of the message is Alice, a process known as a digital signature.

Sslclient must verify the identity of the Sslserver, sslserver whether to verify sslclient identity, is determined by Sslserver. For the authentication process for sslclient and Sslserver, see the 3.2 SSL handshake process.

When authenticating with a digital signature, it is necessary to ensure that the public key of the authenticator is true, otherwise the illegal user may impersonate the authenticator to communicate with the authenticator. 1 See, Cindy impersonate Bob, send his public key to Alice, and use his private key to calculate the signature sent to Alice,alice using "Bob" the public key (in fact, Cindy's public key) successfully validated the signature, Alice felt that Bob's authentication succeeded, What actually communicates with Alice is the Cindy that pretends to be Bob. SSL uses the mechanism provided by PKI to ensure the authenticity of public key, please refer to "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 which can convert key and random length data into fixed-length data under key participation. The process of verifying message integrity using the MAC algorithm is seen in 2. The sender uses the MAC algorithm to calculate the Mac value of the message and sends it to the recipient after the key has been added to the message. The receiver calculates the MAC value of the message using the same key and Mac algorithm, and is compared to the Mac value received. If the two are the same, the message does not change, otherwise the message is altered during transmission and the receiver discards the message.

Figure 2 Mac algorithm

MAC algorithms have features such as the following that enable them to verify the integrity of a message:

Any change in the message will result in a change in the fixed-length data of the output. By comparing the Mac value, you can guarantee that the recipient can discover the change of the message.

The MAC algorithm requires the participation of the key, so illegal users without a key will not be able to add the correct Mac value after changing the contents of the message, so that illegal users can not change the content of the message.

The MAC algorithm requires that the communication two parties have the same key, otherwise the MAC value verification will fail. Therefore, it is necessary to deploy the same key on both sides of the communication before verifying the message integrity with the MAC algorithm. How to deploy your Mac key please see "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 the communication two 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. 3 See, Sslclient (such as a Web browser) uses the public key encryption key of Sslserver (such as webserver) to send the encrypted key to Sslserver, and only the sslserver talent with the corresponding private key obtains 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 sslclient sent to Sslserver cannot be used directly to encrypt data or calculate MAC values, which is the information used to compute the symmetric key and Mac key, known as Premaster secret. Sslclient and Sslserver use Premaster secret to calculate 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. 1 See, Cindy impersonate Bob, send his public key to Alice,alice to use Cindy's public key to encrypt the data sent to Bob, Bob because no corresponding private key can not decrypt the data, and Cindy intercept the data, can use their private key to decrypt the data. SSL uses the mechanism provided by PKI to ensure the authenticity of public key, please refer to "2.5 using PKI to ensure the authenticity of public key".

2.5 Using PKI to guarantee the authenticity of public key

PKI publishes the public key of the user through the digital certificate, and provides the mechanism to verify the authenticity of the public key. A digital certificate (certificate) is a file that includes the user's public key and its identity information, proving 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 Sslclient passes the key encryption to Sslserver, Sslserver needs to send the certificate obtained from the CA to Sslclient,sslclient to infer the authenticity of the certificate through the PKI. Assuming that the certificate does belong to Sslserver, it is sent to sslserver using the public key encryption key in the certificate.

Before verifying the identity of the sslserver/sslclient, Sslserver/sslclient needs to send the certificate obtained from the CA to the peer and the peer to infer the authenticity of the certificate through the PKI. Assuming that the certificate does belong to Sslserver/sslclient, the peer uses the public key in the certificate to verify the identity of the sslserver/sslclient.

3 Protocol Work Process 3.1 SSL hierarchy

Figure 4 SSL Protocol tiering

As seen in 4, SSL is located between the application layer and the transport layer, which provides security assurances for any application-layer protocol that is 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), Sslpassword Change Protocol (SSL cipher Spec protocol) and SSL warning Protocol (SSL alert proto COL);

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

Of

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

L Sslpassword Change Protocol: Client and server are notified to the end through the 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, including the severity level of the alarm and descriptive narration.

L SSL Logging Protocol: mainly responsible for the upper layer of data (SSL handshake Protocol, Sslpassword 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 to the peer.

3.2 SSL Handshake process

SSL negotiates session parameters between the client and server through the handshake process and establishes a session. The session includes 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 cases of handshake are described below:

L only verify the server's SSL handshake process

Verifying the SSL handshake process for the server and client

• Restore the SSL handshake process for the original session

3.2.1 Only verifies the server's SSL handshake process

Figure 5 Verifying the SSL handshake process for the server only

5 See, only need to verify sslserver identity, do not need to verify sslclient identity, the SSL handshake process is:

(1) Sslclient sends its supported SSL version number, encryption algorithm, key exchange algorithm, MAC algorithm and other information to sslserver through the client Hello message.

(2) Sslserver determines the SSL version number and cryptographic suite used for this communication and notifies sslclient through the server Hello message. Assuming Sslserver agrees that Sslclient will reuse this session in future communications, Sslserver assigns the session ID to the session and sends it to sslclient through the server Hello message.

(3) Sslserver sends a digital certificate with its own public key information to sslclient via certificate message.

(4) Sslserver sends the server Hello done message, notifies the Sslclient version number and the cryptographic suite negotiation end, and starts the key exchange.

(5) After sslclient verifies that the Sslserver certificate is valid, the public key in the certificate is used to encrypt sslclient randomly generated premaster secret and sent to Sslserver via client key exchange messages.

(6) Sslclient sends the change CIPHER spec message, notifying sslserver that the message will be encrypted and Mac computed using a negotiated key and encryption suite.

(7) Sslclient 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 Sslserver via finished messages. Sslserver uses the same method to calculate the hash value of the interactive handshake message, and is compared with the decryption result of the finished message, assuming the same, and that the Mac value is validated successfully, the key and cryptographic suite are successfully negotiated.

(8) Similarly, Sslserver sends the change CIPHER spec message, notifying sslclient that the message will be encrypted and Mac-computed using a negotiated key and encryption suite.

(9) Sslserver calculates the hash value of the interactive handshake message, uses the negotiated key and cryptographic suite to process the hash value (calculates and joins the Mac value, encryption, etc.) and sends it to Sslclient via the finished message. Sslclient uses the same method to calculate the hash value of the interactive handshake message, and is compared with the decryption result of the finished message, assuming the same, and that the Mac value is validated successfully, the key and cryptographic suite are successfully negotiated.

After Sslclient receives the finished message sent by Sslserver, assuming the decryption is successful, it is possible to infer that Sslserver is the owner of the digital certificate, that is, sslserver authentication succeeds, The Sslclient authentication to Sslserver is indirectly implemented because only the sslserver talent with the private key is decrypted from the client key exchange message to get the Premaster secret.

& Description:

The change Cipher spec message belongs to the Sslpassword Variation protocol, and the messages that interact with other handshake processes belong to the SSL handshake Protocol, collectively known as the SSL handshake message.

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

3.2.2 Verifying the SSL handshake process between server and client

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

Sslclient authentication is optional and is determined by Sslserver to verify the identity of the sslclient. 6 in the Blue section identifies the content as seen, assuming that Sslserver verifies sslclient identity, then Sslserver and sslclient in addition to the interactive "3.2.1 Only verify the server's SSL handshake process" in the message negotiation key and cryptographic suite, You need to do the following:

(1) Sslserver sends a certificate request message requesting Sslclient to send its certificate to sslserver.

(2) Sslclient sends the certificate with its own public key to sslserver through the certificate message. Sslserver verifies the legality of the certificate.

(3) Sslclient calculates the interactive handshake message, the hash value of the master key, encrypts it with its own private key, and sends it to Sslserver via a certificate verify message.

(4) Sslserver calculates the interactive handshake message, the hash value of the master key, decrypts the certificate verify message with the public key in the Sslclient certificate, and compared the decrypted result to the computed hash value. Assuming both are the same, sslclient 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 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 agrees to reuse the sessions that have been negotiated, with the following detailed procedures:

(1) Sslclient sends the client Hello message, and the session ID in the message is set to the ID of the session that is scheduled for reuse.

(2) Sslserver assumes that the session has been agreed to reuse, and answers by setting the same session ID in the server Hello message. In this way, sslclient and Sslserver can take advantage of the original session's key and cryptographic suite without having to negotiate again.

(3) Sslclient sends the change CIPHER spec message, notifying sslserver that the message will be encrypted and Mac computed using the original session's key and encryption suite.

(4) Sslclient 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 Sslserver to Sslserver infer that the key and cryptographic suite are correct.

(5) Similarly, Sslserver sends the change CIPHER spec message, notifying sslclient that the message will be encrypted and Mac computed using the original session's key and encryption suite.

(6) Sslserver 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 Sslclient to sslclient infer that 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 is widely used in internet banking, e-commerce and other fields to provide security assurance for Web Access.

The application of HTTPS in Internet banking is shown in Figure 8. In order to facilitate customers, a bank provides online banking business, customers can access to the bank's webserver for account inquiries, transfer and so on. By establishing an SSL connection between the customer and the bank's webserver, 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 uses SSL security to provide security for users to access the company's internal network remotely. 9 seen, SSL VPN through the remote access users and SSL VPN gateway to establish an SSL secure connection, agreed that users through a variety of web browsers, various network access methods, regardless of where the remote visit the Enterprise network resources, and can ensure the security of the enterprise network, protect the enterprise internal information is not stolen.

Figure 9 Typical networking environment for SSL VPN

How SSL Works

Related Article

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.