14 Appendix C - The SSL/TLS handshake

14.1.1 When a client connects to a server using https, it is connecting using SSL/TLS.

14.1.2 Before the server responds to the clients application request, the client and server swap certificates, negotiate an encryption algorithm, and a shared encryption key. This process is called a handshake.

14.1.3 The server needs to be configured to ensure the handshake only allows preferred encryption algorithms, key lengths, and checks certificate status.

14.1.4 The following discusses the key aspects of the handshake where the server needs to be configured to make appropriate decisions.

14.2 Sample handshake

14.2.1 As per RFC 2246 (http://www.ietf.org/rfc/rfc2246.txt) the handshake involves the following steps:

• Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption.

• Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret.

• Exchange certificates and cryptographic information to allow the client and server to authenticate themselves.

• Generate a master secret from the premaster secret and exchanged random values. TLS/SSL differ in the way this "shared" master secret is created, and TLS is preferred.

• Provide security parameters to the record layer.

• Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker.

14.2.2 The following table, also from RFC 2246, illustrates the process.

Fig. 1 - Message flow for a full handshake

* Indicates optional or situation-dependent messages that are not always sent.

14.2.9 During the ClientHello and ServerHello, the client and server agree on algorithms, and exchange random values. For a S.E.E. Application it is important that the algorithm chosen is acceptable (3DES or AES), and that the random values are generated well.

14.2.10 To prompt the user for a certificate, the server must be configured to send a CertificateRequest during the ServerHello. This request contains a list of CAs that the server trust, to help the client choose an appropriate certificate, this will probably be generated from the list of CAs the server is configured to trust.

14.2.11 The client should drop the connection if the server certificate has been revoked (by checking the CRL or OCSP services specified in the certificate), the certificate is expired or not yet valid, or if a current CRL or OCSP response is unavailable, the signature is not good, or if the certificate has not been issued by a trusted CA.

14.2.12 The client must warn the user, and should drop the connection, if the certificate has been revoked, the certificate is expired or not yet valid, or if a current CRL or OCSP response is unavailable.

14.2.13 Note that Netscape Navigator 4 and Internet Explorer 5 can be configured to warn the user but not to drop the connection, if the server certificate is not valid. Also note that by default these products do not check server certificates for revocation.

14.2.14 For SENSITIVE systems, if the client does not respond with a certificate, the server should deny access. For IN CONFIDENCE systems, the system may offer a different authentication mechanism, for example a username/password prompt.

14.2.15 The server must check the client certificate against the CRL or OCSP service specified in the certificate.

14.2.16 The server must drop the connection if the certificate has been revoked, the certificate is expired or not yet valid, or if a current CRL or OCSP response is unavailable, the signature is not good, or if the certificate has not been issued by a trusted CA.

14.2.17 Clearly, the server must be able to be configured to specify which CAs are trusted.

14.2.18 The user has now been authenticated to the server (i.e. the user's certificate details should now be accessible to the server application and the server can be confident that the other end of the connection is the individual specified by the certificate), the application must now be able to make use of this information to authorise access.