Every certificate includes a public key which a part of asymmetric key pair. The public key is freely provided to anyone who is interested. The corresponding private key is kept locked and is available only to the server. Anything that’s encrypted with one of the keys is decipherable with the other. In other words client can retrieve the public key and use it to encode a secret message that can be deciphered only with the corresponding private key, i.e. the client can create a message that only the server can read.
The described process is called asymmetric encryption, and it’s a basic building block of SSL. Its basic principle is that you can’t determine a private key by analyzing the corresponding public key. Asymmetric encryption is much slower and generates much larger messages than symmetric encryption. Another type of encryption mechanism is symmetric which uses the same secret key to encrypt a message as to decipher it. In this case both parties need to know the secret value in order to have a conversation. Unfortunately, you can’t transmit this information over the internet, because a malicious user might intercept it and then be able to decipher the following encrypted conversation. SSL combines both encryption possibilities:
– Asymmetric encryption manages the initial key exchange
– Secret value symmetrically encrypts all subsequent messages, which ensures the best possible performance.
The whole process works like this, where the client refers to the web browser running on the end user’s machine and the server refers to the web server hosting the websites the user wants to get access to:
1. The client sends a request to connect to the server.
2. The server signs its certificate and sends it to the client. This settles the handshake portion of the exchange.
3. The client checks whether the certificate was issued by a Certification Authorities (CA) it trusts. If so, it proceeds to the next step. In a web browser scenario, the client may warn the user with an ominous-sounding message if it does not recognize the CA, and allows the user to decide whether to proceed. The client recognizes CAs when their certificate is stored in the Trusted Root Certification Authorities store of the operating system. You can find certificates stored in this store through the Internet Explorer options by clicking the Certificates button on the Content tab.
4. The client compares the information in the certificate with the information received from the site (including its domain name and its public key). The client also verifies that the server-side certificate is valid, has not been revoked, and is issued by a trusted CA. Then the client accepts the connection.
5. The client tells the server what encryption keys it supports for communication.
6. The server chooses the strongest shared key length and informs the client.
7. Using the indicated key length, the client randomly generates a symmetric encryption key. This will be used for the duration of the transaction between the server and the client. It ensures optimum performance, because symmetric encryption is much faster than asymmetric encryption.
8. The client encrypts the session key using the server’s public key (from the certificate), and then it sends the encrypted session key to the server.
9. The server receives the encrypted session key and deciphers it using its private key. Both the client and server now have the shared secret key, and they can use it to encrypt all communication for the duration of the session.
Security risk is limited, because the symmetric key is generated randomly and used only for the duration of a session. In this way:
– It’s difficult to break encrypted messages using cryptanalysis, because messages from other sessions cannot be used
– If the key is found by a malicious user, it will remain valid only for the progress of session
Applying this technology is interesting to know, that the client must generate the symmetric key, because the client has the server’s public key. This key can be used to encrypt a message that only the server can read. The server does not have corresponding information about the client and thus cannot yet encrypt a message. The important thing here is if the client supplies a weak key, the entire interaction could be compromised. For example, older versions of the browsers used a weak random number generator to create the symmetric key and for a malicious user will be much easier to guess the key.