SSL/TLS handshake

The SSL/TLS handshaking process occurs during the initial connection request between the SSL/TLS client and server, when authentication and negotiation of CipherSuites is performed.

All the supported SSL/TLS CipherSuites (see SSL/TLS support), with the exception of the anonymous CipherSuites, require server authentication and allow client authentication; the server can be configured to request client authentication. We should avoid using anonymous CipherSuites because they provide no guarantees about the identity of the remote peer. It is possible for a man-in-the-middle attack to intercept anonymous SSL/TLS connections without your knowledge. Use anonymous CipherSuites only on trustworthy internal networks and only if we are prepared to accept the risk of data interception.

The communication peer authentication in SSL/TLS is based on public key cryptography and X.509v3 digital certificates. A site that should be authenticated in the SSL/TLS protocol requires a private key and a digital certificate (which contains the corresponding public key together with the information about the site's identity), validity time of the certificate. The certificates are signed by a Certification Authority, the certificates of such authorities are called signer certificates. A certificate followed by one or more signer certificates constitute a certificate chain. A certificate chain is characterized by the fact that, starting from the first certificate (site certificate), the signature of each certificate in the chain can be verified using the public key contained in the next signer certificate.

When a secure connection requiring server authentication is being established the server sends to the client a certificate chain to prove its identity. The SSL/TLS client will pursue the connection establishment to the server only if it can authenticate the server, for example, verify the signature of the server's site certificate. In order to verify that signature the SSL/TLS client needs to trust the server site itself or at least one of the signers in the certificate chain provided by the server. The certificates of the trusted sites and signers must be maintained on the client side to perform this verification.

The SSL/TLS client inspects the server's certificate chain, starting with the site certificate. The client considers the signature of the site certificate to be valid in the following circumstances:

• The site certificate is in the repository of the trusted site or signer certificates
• A signer certificate in the chain can be validated based on its repository of trusted signer certificates

In the latter case, the SSL/TLS client checks that the certificate chain is indeed correctly signed, from the trusted signer certificate down to the server's site certificate. Each certificate involved in this process is also examined for correctness of format and dates of validity. If any of these checks fail, the connection to the server is refused. After verifying the server certificate the client uses the public key embedded in that certificate in the next steps of the SSL/TLS protocol. The SSL/TLS connection can only be established if the server really has the corresponding private key.

The client authentication follows the same procedure: if a SSL/TLS server requires client authentication the client sends to the server a certificate chain to prove its identity. The server verifies the chain based on its repository of trusted site and signer certificates. After verifying the client's certificate the server uses the public key embedded in that certificate in the next steps of the SSL/TLS protocol. The SSL/TLS connection can only be established if the client really has the corresponding private key.

Recent versions of the TLS protocols provide high security communications (SSL and older TLS protocols are considered insecure). However, the protocol operates based on the information provided by the application. Only if that information base is also maintained securely the overall goal of secure communication can be achieved. For example, if your repository of trusted site and signer certificates is compromised, you might establish a secure connection to a very insecure communication partner.

Parent topic: SSL/TLS support