How SSL Works

SSL is a security protocol that provides the use of TCP/IP privacy and integrity of communications applications. 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.

Figure SSL Client-to-server authentication handshake

(1) The client sends a client "Hello" message (sorted in client preference order) that lists the client's password capabilities, such as the version of SSL, the client-supported password pair (cryptographic suite), and the data compression method (hash function) 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.

How SSL Works