|
While some sites may require a user to present a digital certificate before they release sensitive information, your computer doesn't need one to access a site. However, the Web server does. To answer the second part of your question, let's take a look at how a secure session, using digital certificates and SSL works.
When your computer, also known as the client, uses the HTTPS protocol to request a secure Web page, it initiates a secure session with the Web site by sending a Client Hello message to the server. This message contains information about which encryption and compression algorithms the client supports and a pseudorandom number.
The Web server responds with a Server Hello message, which contains information about server supported algorithms and a pseudorandom number. The server chooses the strongest cipher that both the client and server support. The server also sends the client a digital certificate. The server must always present its certificate to the client, but if the server doesn't require client authentication the client is not required to send a certificate. The server will then send a Server Hello Done Message, indicating it is finished and is waiting for the client's response.
Once the client receives the server's message, it checks the certification hierarchy of the server's certificate. The server's certificate contains its public key, which the client uses to authenticate the server and verify that the name of the server in the certificate matches the name the client used to start the session. For example, if the user enters https://www.secureserver.com for the URL, the certificate should contain a subject name of www.secureserver.com or *.secureserver.com.
The client then computes a premastered secret using the two random values that were generated during the Client and Server Hello messages. This premastered secret is encrypted using the public key from the server's certificate and is sent to the server in a a Client Key Exchange message. If the server can decrypt this, the client is assured that the server has the correct private key. This step is crucial to prove the authenticity of the server. Only the server with the correct private key can decrypt this data and continue the protocol negotiation.
This handshake sequence securely exchanges data that is then used by both the client and the server to calculate a Master Secret key. Because both the server and the client can calculate the Master Secret key, it does not need to be exchanged. The server can now respond to the client with a request to begin communicating using the established keys and parameters.
|
