How SSL works

How SSL works

SSL is a security protocol that provides communication applications using TCP/IP.ProgramPrivacy and integrity. InternetHypertext Transfer Protocol(HTTP) uses SSL for secure communication. The data transmitted between the client and the server is symmetricAlgorithm(Such as des or RC4. The Public Key algorithm (generally RSA) is used to obtain the encryption key exchange and digital signature. This algorithm uses the public key in the SSL digital certificate of the server. With the SSL digital certificate of the server, the client can also verify the identity of the server. SSL protocol versions 1 and 2 only provide server authentication. Version 3 adds client authentication. This authentication requires both client and server digital certificates. SSL handshake SSL connections are always started by the client. Execute the SSL handshake when the SSL session starts. The handshake generates the Password parameters of the session. Shows a brief overview of how to handle SSL handshakes. This example assumes that an SSL connection has been established between the web browser and the web server. Figure ssl client-server authentication handshake (1) the client sends "hello" messages (sorted by client preferences) listing client passwords ), for example, the SSL version, password pairs supported by the client, and data compression methods 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. The message 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. Generally, the server selects the largest public password pair. (3) the server sends its SSL digital certificate. (The server uses an X.509 V3 digital certificate with SSL .) If the server uses SSL V3 and the server application (such as the Web server) needs a digital certificate for client authentication, the client sends a "digital certificate request" message. In the "digital certificate request" message, the server sends a list of supported client digital certificate types and names of acceptable CAS. (4) the server sends the "Hello!" message to the server and waits for the response from the client. (5) Upon receiving the "Hello!" Message from the server, the client (Web browser) will verify the validity of the server's SSL digital certificate and check whether the "hello" Message Parameter of the server is acceptable. If the server requests a client digital certificate, the client sends its digital certificate; or, if no suitable digital certificate is available, the client sends the "no digital certificate" Warning. This warning is only a warning, but if the client digital certificate authentication is mandatory, the server application will cause the session to fail. (6) the client sends the "client key exchange" message. This message containsPre-master secret(A random number of 46 bytes used in symmetric encryption key generation), andMessage AuthenticationCode (Mac) Key (encrypted with the public key of the server ). If the client sends the client digital certificate to the server, the client sends the "digital certificate verification" Message signed with the client's private key. By verifying the signature of this message, the server can display the ownership of the client digital certificate. Note::If the server does not have a dedicated key for the digital certificate, it cannot decrypt the pre-master password, nor create the correct key for the symmetric encryption algorithm, and the handshake will fail. (7) The client converts the pre-master secretMaster secretAll keys used for encryption and message authentication are derived. Then, the client sends a "Change Password specification" message to convert the server to a new negotiated password pair. The next message ("unfinished" Message) sent by the client is the first message encrypted using this password method and key. (8) The server responds with its own "Change Password specifications" and "completed" messages. (9) The SSL handshake ends and the encrypted application data can be sent.