Next: , Previous: , Up: Internal architecture of GnuTLS   [Contents][Index]


10.4 TLS Extension Handling

As with authentication methods, adding TLS hello extensions can be done quite easily by implementing the interface shown below.

typedef int (*gnutls_ext_recv_func) (gnutls_session_t session,
                                     const unsigned char *data, size_t len);
typedef int (*gnutls_ext_send_func) (gnutls_session_t session,
                                     gnutls_buffer_st *extdata);

Here there are two main functions, one for parsing the received extension data and one for formatting the extension data that must be send. These functions have to check internally whether they operate within a client or a server session.

A simple example of an extension handler can be seen in lib/ext/srp.c in GnuTLS’ source code. After implementing these functions, the extension has to be registered. Registering an extension can be done in two ways. You can create a GnuTLS internal extension and register it in hello_ext.c or write an external extension (not inside GnuTLS but inside an application using GnuTLS) and register it via the exported functions gnutls_session_ext_register or gnutls_ext_register.

Adding a new TLS hello extension

Adding support for a new TLS hello extension is done from time to time, and the process to do so is not difficult. Here are the steps you need to follow if you wish to do this yourself. For the sake of discussion, let’s consider adding support for the hypothetical TLS extension foobar. The following section is about adding an hello extension to GnuTLS itself. For custom application extensions you should check the exported functions gnutls_session_ext_register or gnutls_ext_register.

Add configure option like --enable-foobar or --disable-foobar.

This step is useful when the extension code is large and it might be desirable under some circumstances to be able to leave out the extension during compilation of GnuTLS. If you don’t need this kind of feature this step can be safely skipped.

Whether to choose enable or disable depends on whether you intend to make the extension be enabled by default. Look at existing checks (i.e., SRP, authz) for how to model the code. For example:

AC_MSG_CHECKING([whether to disable foobar support])
AC_ARG_ENABLE(foobar,
	AS_HELP_STRING([--disable-foobar],
		[disable foobar support]),
	ac_enable_foobar=no)
if test x$ac_enable_foobar != xno; then
 AC_MSG_RESULT(no)
 AC_DEFINE(ENABLE_FOOBAR, 1, [enable foobar])
else
 ac_full=0
 AC_MSG_RESULT(yes)
fi
AM_CONDITIONAL(ENABLE_FOOBAR, test "$ac_enable_foobar" != "no")

These lines should go in lib/m4/hooks.m4.

Add an extension identifier to extensions_t in gnutls_int.h.

A good name for the identifier would be GNUTLS_EXTENSION_FOOBAR. If the extension that you are implementing is an extension that is officially registered by IANA then it is recommended to use its official name such that the extension can be correctly identified by other developers. Check with http://www.iana.org/assignments/tls-extensiontype-values for registered extensions.

Register the extension in lib/hello_ext.c.

In order for the extension to be executed you need to register it in the static hello_ext_entry_st const *extfunc[] list in lib/hello_ext.c.

A typical entry would be:

#ifdef ENABLE_FOOBAR
	[GNUTLS_EXTENSION_FOOBAR] = &ext_mod_foobar,
#endif

Also for every extension you need to create an hello_ext_entry_st that describes the extension. This structure is placed in the designated c file for your extension and its name is used in the registration entry as depicted above.

The structure of hello_ext_entry_st is as follows:

  const hello_ext_entry_st ext_mod_foobar = {
    .name = "FOOBAR",
    .tls_id = 255,
    .gid = GNUTLS_EXTENSION_FOOBAR,
    .parse_type = GNUTLS_EXT_TLS,
    .validity = GNUTLS_EXT_FLAG_CLIENT_HELLO |
	GNUTLS_EXT_FLAG_TLS12_SERVER_HELLO |
	GNUTLS_EXT_FLAG_TLS13_SERVER_HELLO |
	GNUTLS_EXT_FLAG_TLS,
    .recv_func = _gnutls_foobar_recv_params,
    .send_func = _gnutls_foobar_send_params,
    .pack_func = _gnutls_foobar_pack,
    .unpack_func = _gnutls_foobar_unpack,
    .deinit_func = _gnutls_foobar_deinit,
    .cannot_be_overriden = 1
  };

The GNUTLS_EXTENSION_FOOBAR is the identifier that you’ve added to gnutls_int.h earlier. The .tls_id should contain the number that IANA has assigned to this extension, or an unassigned number of your choice if this is an unregistered extension. In the rest of this structure you specify the functions to handle the extension data. The receive function will be called upon reception of the data and will be used to parse or interpret the extension data. The send function will be called prior to sending the extension data on the wire and will be used to format the data such that it can be send over the wire. The pack and unpack functions will be used to prepare the data for storage in case of session resumption (and vice versa). The deinit function will be called to deinitialize the extension’s private parameters, if any.

Look at gnutls_ext_parse_type_t and gnutls_ext_flags_t for a complete list of available flags.

Note that the conditional ENABLE_FOOBAR definition should only be used if step 1 with the configure options has taken place.

Add new files that implement the hello extension.

To keep things structured every extension should have its own files. The functions that you should (at least) add are those referenced in the struct from the previous step. Use descriptive file names such as lib/ext/foobar.c and for the corresponding header lib/ext/foobar.h. As a starter, you could add this:

int
_gnutls_foobar_recv_params (gnutls_session_t session, const uint8_t * data,
                     size_t data_size)
{
  return 0;
}

int
_gnutls_foobar_send_params (gnutls_session_t session, gnutls_buffer_st* data)
{
  return 0;
}

int
_gnutls_foobar_pack (extension_priv_data_t epriv, gnutls_buffer_st * ps)
{
   /* Append the extension's internal state to buffer */
   return 0;
}

int
_gnutls_foobar_unpack (gnutls_buffer_st * ps, extension_priv_data_t * epriv)
{
   /* Read the internal state from buffer */
   return 0;
}

The _gnutls_foobar_recv_params function is responsible for parsing incoming extension data (both in the client and server).

The _gnutls_foobar_send_params function is responsible for formatting extension data such that it can be send over the wire (both in the client and server). It should append data to provided buffer and return a positive (or zero) number on success or a negative error code. Previous to 3.6.0 versions of GnuTLS required that function to return the number of bytes that were written. If zero is returned and no bytes are appended the extension will not be sent. If a zero byte extension is to be sent this function must return GNUTLS_E_INT_RET_0.

If you receive length fields that don’t match, return GNUTLS_E_UNEXPECTED_PACKET_LENGTH. If you receive invalid data, return GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER. You can use other error codes from the list in Error codes. Return 0 on success.

An extension typically stores private information in the session data for later usage. That can be done using the functions _gnutls_hello_ext_set_datum and _gnutls_hello_ext_get_datum. You can check simple examples at lib/ext/max_record.c and lib/ext/server_name.c extensions. That private information can be saved and restored across session resumption if the following functions are set:

The _gnutls_foobar_pack function is responsible for packing internal extension data to save them in the session resumption storage.

The _gnutls_foobar_unpack function is responsible for restoring session data from the session resumption storage.

When the internal data is stored using the _gnutls_hello_ext_set_datum, then you can rely on the default pack and unpack functions: _gnutls_hello_ext_default_pack and _gnutls_hello_ext_default_unpack.

Recall that both for the client and server, the send and receive functions most likely will need to do different things depending on which mode they are in. It may be useful to make this distinction explicit in the code. Thus, for example, a better template than above would be:

int
_gnutls_foobar_recv_params (gnutls_session_t session,
                            const uint8_t * data,
                            size_t data_size)
{
  if (session->security_parameters.entity == GNUTLS_CLIENT)
    return foobar_recv_client (session, data, data_size);
  else
    return foobar_recv_server (session, data, data_size);
}

int
_gnutls_foobar_send_params (gnutls_session_t session,
                            gnutls_buffer_st * data)
{
  if (session->security_parameters.entity == GNUTLS_CLIENT)
    return foobar_send_client (session, data);
  else
    return foobar_send_server (session, data);
}

The functions used would be declared as static functions, of the appropriate prototype, in the same file.

When adding the new extension files, you’ll need to add them to lib/ext/Makefile.am as well, for example:

if ENABLE_FOOBAR
libgnutls_ext_la_SOURCES += ext/foobar.c ext/foobar.h
endif

Add API functions to use the extension.

It might be desirable to allow users of the extension to request the use of the extension, or set extension specific data. This can be implemented by adding extension specific function calls that can be added to includes/gnutls/gnutls.h, as long as the LGPLv2.1+ applies. The implementation of these functions should lie in the lib/ext/foobar.c file.

To make the API available in the shared library you need to add the added symbols in lib/libgnutls.map, so that the symbols are exported properly.

When writing GTK-DOC style documentation for your new APIs, don’t forget to add Since: tags to indicate the GnuTLS version the API was introduced in.

Adding a new Supplemental Data Handshake Message

TLS handshake extensions allow to send so called supplemental data handshake messages [RFC4680]. This short section explains how to implement a supplemental data handshake message for a given TLS extension.

First of all, modify your extension foobar in the way, to instruct the handshake process to send and receive supplemental data, as shown below.

int
_gnutls_foobar_recv_params (gnutls_session_t session, const opaque * data,
                                 size_t _data_size)
{
   ...
   gnutls_supplemental_recv(session, 1);
   ...
}

int
_gnutls_foobar_send_params (gnutls_session_t session, gnutls_buffer_st *extdata)
{
   ...
   gnutls_supplemental_send(session, 1);
   ...
}

Furthermore you’ll need two new functions _foobar_supp_recv_params and _foobar_supp_send_params, which must conform to the following prototypes.

typedef int (*gnutls_supp_recv_func)(gnutls_session_t session,
                                     const unsigned char *data,
                                     size_t data_size);
typedef int (*gnutls_supp_send_func)(gnutls_session_t session,
                                     gnutls_buffer_t buf);

The following example code shows how to send a “Hello World” string in the supplemental data handshake message.

int
_foobar_supp_recv_params(gnutls_session_t session, const opaque *data, size_t _data_size)
{
   uint8_t len = _data_size;
   unsigned char *msg;

   msg = gnutls_malloc(len);
   if (msg == NULL) return GNUTLS_E_MEMORY_ERROR;

   memcpy(msg, data, len);
   msg[len]='\0';

   /* do something with msg */
   gnutls_free(msg);

   return len;
}

int
_foobar_supp_send_params(gnutls_session_t session, gnutls_buffer_t buf)
{
   unsigned char *msg = "hello world";
   int len = strlen(msg);

   if (gnutls_buffer_append_data(buf, msg, len) < 0)
       abort();

   return len;
}

Afterwards, register the new supplemental data using gnutls_session_supplemental_register, or gnutls_supplemental_register at some point in your program.


Next: , Previous: , Up: Internal architecture of GnuTLS   [Contents][Index]