3.5 The TLS Handshake Protocol

The Handshake protocol is responsible for the ciphersuite negotiation, the initial key exchange, and the authentication of the two peers. This is fully controlled by the application layer, thus your program has to set up the required parameters. Available functions to control the handshake protocol include:

gnutls_cipher_set_priority:

To set the priority of bulk cipher algorithms.

gnutls_mac_set_priority:

To set the priority of MAC algorithms.

gnutls_kx_set_priority:

To set the priority of key exchange algorithms.

gnutls_compression_set_priority:

To set the priority of compression methods.

gnutls_certificate_type_set_priority:

To set the priority of certificate types (e.g., OpenPGP, X.509).

gnutls_protocol_set_priority:

To set the priority of protocol versions (e.g., SSL 3.0, TLS 1.0).

gnutls_set_default_priority:

To set some defaults in the current session. That way you don't have to call each priority function, independently, but you have to live with the defaults.

gnutls_credentials_set:

To set the appropriate credentials structures.

gnutls_certificate_server_set_request:

To set whether client certificate is required or not.

gnutls_handshake:

To initiate the handshake.

3.5.1 TLS cipher suites

The Handshake Protocol of TLS negotiates cipher suites of the form TLS_DHE_RSA_WITH_3DES_CBC_SHA. The usual cipher suites contain these parameters:

• The key exchange algorithm. DHE_RSA in the example.
• The Symmetric encryption algorithm and mode 3DES_CBC in this example.
• The MAC¹ algorithm used for authentication. MAC_SHA is used in the above example.

The cipher suite negotiated in the handshake protocol will affect the Record Protocol, by enabling encryption and data authentication. Note that you should not over rely on TLS to negotiate the strongest available cipher suite. Do not enable ciphers and algorithms that you consider weak.

The priority functions, dicussed above, allow the application layer to enable and set priorities on the individual ciphers. It may imply that all combinations of ciphersuites are allowed, but this is not true. For several reasons, not discussed here, some combinations were not defined in the TLS protocol. The supported ciphersuites are shown in ciphersuites.

3.5.2 Client authentication

In the case of ciphersuites that use certificate authentication, the authentication of the client is optional in TLS. A server may request a certificate from the client — using the gnutls_certificate_server_set_request function. If a certificate is to be requested from the client during the handshake, the server will send a certificate request message that contains a list of acceptable certificate signers. In GnuTLS the certificate signers list is constructed using the trusted Certificate Authorities by the server. That is the ones set using

• gnutls_certificate_set_x509_trust_file
• gnutls_certificate_set_x509_trust_mem

Sending of the names of the CAs can be controlled using gnutls_certificate_send_x509_rdn_sequence. The client, then, may send a certificate, signed by one of the server's acceptable signers.

3.5.3 Resuming Sessions

The gnutls_handshake function, is expensive since a lot of calculations are performed. In order to support many fast connections to the same server a client may use session resuming. Session resuming is a feature of the TLS protocol which allows a client to connect to a server, after a successful handshake, without the expensive calculations. This is achieved by using the previously established keys. GnuTLS supports this feature, and the example (see ex:resume-client) illustrates a typical use of it.

Keep in mind that sessions are expired after some time, for security reasons, thus it may be normal for a server not to resume a session even if you requested that. Also note that you must enable, using the priority functions, at least the algorithms used in the last session.

3.5.4 Resuming internals

The resuming capability, mostly in the server side, is one of the problems of a thread-safe TLS implementations. The problem is that all threads must share information in order to be able to resume sessions. The gnutls approach is, in case of a client, to leave all the burden of resuming to the client. I.e., copy and keep the necessary parameters. See the functions:

• gnutls_session_get_data
• gnutls_session_get_id
• gnutls_session_set_data

The server side is different. A server has to specify some callback functions which store, retrieve and delete session data. These can be registered with:

• gnutls_db_set_remove_function
• gnutls_db_set_store_function
• gnutls_db_set_retrieve_function
• gnutls_db_set_ptr

It might also be useful to be able to check for expired sessions in order to remove them, and save space. The function gnutls_db_check_entry is provided for that reason.