

The SSL handshake process: Public and privates keys explained

Expert Michael Cobb details the SSL handshake and the role of public and private keys in a C2B transaction.

I read your piece that explained how trusted SSL certificates and forged SSL certificates work, and I still need...

public and private keys explained in more detail. Plus, please explain in more detail the exact difference between the public and private key, and the role that the certificate plays in the following situations:

  • A consumer-to-website transaction (i.e., what happens when someone buys something on Amazon); and
  • A true B2B transaction, in which servers talk to servers.

A consumer's browser begins the SSL handshake process by requesting a secure Web page using the HTTPS protocol. This initiates a secure session with the website by sending a Client Hello message to the Web server. The Client Hello message contains information about which encryption and compression algorithms the browser supports, as well as a pseudo-random number. The Web server responds with a Server Hello message, which also includes information about supported algorithms and a pseudo-random number. The Web server chooses the strongest cipher that both the browser and server support. The server also sends its digital certificate to the browser to vouch for the identity of an individual or a computer system. The Web server then sends a Server Hello Done message indicating that it is finished and awaiting a response from the browser.

Ask a question

SearchSecurity.com expert Michael Cobb is standing by to answer your questions about enterprise application security and platform security. Submit your question via email at [email protected].

Once the browser receives the server's message, it checks the certificate against a list of known Certificate Authorities to ensure the certificate is valid. The server's certificate contains its public key and the name of the server, which must match the name of the server the browser requested. For example, if the user typed the URL "https://www.secureserver.com" in the browser, the certificate should contain a subject name of "www.secureserver.com" or "*.secureserver.com."

The client then computes a premaster secret using the two random values that were generated during the Client and Server Hello messages. This premaster secret is encrypted using the public key from the server's certificate and sent in a Client Key Exchange message to the server. If the server can decrypt this data, the client is assured that the server has the correct private key. A message encrypted with a public key can only be decrypted by the matching private key, and visa versa. This step is crucial to proving the authenticity of the server. Only the server with the private key that matches the public key in the certificate can decrypt this data and continue to the protocol negotiation.

The SSL handshake process 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 browser with a request to begin communicating using the established keys and parameters. Thus, by combining SSL with a Web server's digital certificate, a consumer can establish a secure connection to a website without having to pass secret encryption keys in the clear.

This was last published in August 2012

Dig Deeper on Web application and API security best practices