Next: Associating the credentials, Previous: Preparation, Up: How to use GnuTLS in applications [Contents][Index]
In the previous sections we have discussed the global initialization required for GnuTLS as well as the initialization required for each authentication method’s credentials (see Authentication). In this section we elaborate on the TLS or DTLS session initiation. Each session is initialized using gnutls_init which among others is used to specify the type of the connection (server or client), and the underlying protocol type, i.e., datagram (UDP) or reliable (TCP).
session: is a pointer to a gnutls_session_t type.
flags: indicate if this session is to be used for server or client.
This function initializes the provided session. Every session must
be initialized before use, and after successful initialization and
use must be deinitialized by calling gnutls_deinit() .
flags can be any combination of flags from gnutls_init_flags_t .
Note that since version 3.1.2 this function enables some common
TLS extensions such as session tickets and OCSP certificate status
request in client side by default. To prevent that use the GNUTLS_NO_DEFAULT_EXTENSIONS
flag.
Note that it is never mandatory to use gnutls_deinit() after this
function fails. Since gnutls 3.8.0, it is safe to unconditionally
use gnutls_deinit() even after failure regardless of whether the
memory was initialized prior to gnutls_init() ; however, clients
wanting to be portable to older versions of the library should
either skip deinitialization on failure, or pre-initialize the
memory passed in to gnutls_init() to all zeroes via memset() or
similar.
Returns: GNUTLS_E_SUCCESS on success, or an error code.
GNUTLS_SERVERConnection end is a server.
GNUTLS_CLIENTConnection end is a client.
GNUTLS_DATAGRAMConnection is datagram oriented (DTLS). Since 3.0.0.
GNUTLS_NONBLOCKConnection should not block. Since 3.0.0.
GNUTLS_NO_DEFAULT_EXTENSIONSDo not enable any TLS extensions by default such as session tickets and OCSP certificate status request (since 3.1.2). As TLS 1.2 and later require extensions this option is considered obsolete and should not be used.
GNUTLS_NO_REPLAY_PROTECTIONDisable any replay protection in DTLS. This must only be used if replay protection is achieved using other means. Since 3.2.2.
GNUTLS_NO_SIGNALIn systems where SIGPIPE is delivered on send, it will be disabled. That flag has effect in systems which support the MSG_NOSIGNAL sockets flag (since 3.4.2).
GNUTLS_ALLOW_ID_CHANGEAllow the peer to replace its certificate, or change its ID during a rehandshake. This change is often used in attacks and thus prohibited by default. Since 3.5.0.
GNUTLS_ENABLE_FALSE_STARTEnable the TLS false start on client side if the negotiated ciphersuites allow it. This will enable sending data prior to the handshake being complete, and may introduce a risk of crypto failure when combined with certain key exchanged; for that GnuTLS may not enable that option in ciphersuites that are known to be not safe for false start. Since 3.5.0.
GNUTLS_FORCE_CLIENT_CERTWhen in client side and only a single cert is specified, send that certificate irrespective of the issuers expected by the server. Since 3.5.0.
GNUTLS_NO_TICKETSFlag to indicate that the session should not use resumption with session tickets.
GNUTLS_KEY_SHARE_TOPGenerate key share for the first group which is enabled. For example x25519. This option is the most performant for client (less CPU spent generating keys), but if the server doesn’t support the advertised option it may result to more roundtrips needed to discover the server’s choice.
GNUTLS_KEY_SHARE_TOP2Generate key shares for the top-2 different groups which are enabled. For example (ECDH + x25519). This is the default.
GNUTLS_KEY_SHARE_TOP3Generate key shares for the top-3 different groups which are enabled.
That is, as each group is associated with a key type (EC, finite field, x25519), generate
three keys using GNUTLS_PK_DH , GNUTLS_PK_EC , GNUTLS_PK_ECDH_X25519 if all of them are enabled.
GNUTLS_POST_HANDSHAKE_AUTHEnable post handshake authentication for server and client. When set and
a server requests authentication after handshake GNUTLS_E_REAUTH_REQUEST will be returned
by gnutls_record_recv() . A client should then call gnutls_reauth() to re-authenticate.
GNUTLS_NO_AUTO_REKEYDisable auto-rekeying under TLS1.3. If this option is not specified gnutls will force a rekey after 2^24 records have been sent.
GNUTLS_SAFE_PADDING_CHECKFlag to indicate that the TLS 1.3 padding check will be done in a safe way which doesn’t leak the pad size based on GnuTLS processing time. This is of use to applications which hide the length of transferred data via the TLS1.3 padding mechanism and are already taking steps to hide the data processing time. This comes at a performance penalty.
GNUTLS_ENABLE_EARLY_STARTUnder TLS1.3 allow the server to return earlier than the full handshake finish; similarly to false start the handshake will be completed once data are received by the client, while the server is able to transmit sooner. This is not enabled by default as it could break certain existing server assumptions and use-cases. Since 3.6.4.
GNUTLS_ENABLE_RAWPKAllows raw public-keys to be negotiated during the handshake. Since 3.6.6.
GNUTLS_AUTO_REAUTHEnable transparent re-authentication in client side when the server
requests to. That is, reauthentication is handled within gnutls_record_recv() , and
the GNUTLS_E_REHANDSHAKE or GNUTLS_E_REAUTH_REQUEST are not returned. This must be
enabled with GNUTLS_POST_HANDSHAKE_AUTH for TLS1.3. Enabling this flag requires to restore
interrupted calls to gnutls_record_recv() based on the output of gnutls_record_get_direction() ,
since gnutls_record_recv() could be interrupted when sending when this flag is enabled.
Note this flag may not be used if you are using the same session for sending and receiving
in different threads.
GNUTLS_ENABLE_EARLY_DATAUnder TLS1.3 allow the server to receive early data sent as part of the initial ClientHello (0-RTT). This can also be used to explicitly indicate that the client will send early data. This is not enabled by default as early data has weaker security properties than other data. Since 3.6.5.
GNUTLS_NO_AUTO_SEND_TICKETUnder TLS1.3 disable auto-sending of session tickets during the handshake.
GNUTLS_NO_END_OF_EARLY_DATAUnder TLS1.3 suppress sending EndOfEarlyData message. Since 3.7.2.
GNUTLS_NO_TICKETS_TLS12Flag to indicate that the session should not use resumption with session tickets. This flag only has effect if TLS 1.2 is used.
GNUTLS_NO_STATUS_REQUESTPrevents client from including the "status_request" TLS extension in the client hello, thus disabling the receival of certificate status information. Since 3.8.0.
Figure 6.2: The gnutls_init_flags_t enumeration.
After the session initialization details on the allowed ciphersuites and protocol versions should be set using the priority functions such as gnutls_priority_set and gnutls_priority_set_direct. We elaborate on them in Priority Strings. The credentials used for the key exchange method, such as certificates or usernames and passwords should also be associated with the session current session using gnutls_credentials_set.
session: is a gnutls_session_t type.
type: is the type of the credentials
cred: the credentials to set
Sets the needed credentials for the specified type. E.g. username,
password - or public and private keys etc. The cred parameter is
a structure that depends on the specified type and on the current
session (client or server).
In order to minimize memory usage, and share credentials between
several threads gnutls keeps a pointer to cred, and not the whole
cred structure. Thus you will have to keep the structure allocated
until you call gnutls_deinit() .
For GNUTLS_CRD_ANON , cred should be
gnutls_anon_client_credentials_t in case of a client. In case of
a server it should be gnutls_anon_server_credentials_t .
For GNUTLS_CRD_SRP , cred should be gnutls_srp_client_credentials_t
in case of a client, and gnutls_srp_server_credentials_t , in case
of a server.
For GNUTLS_CRD_CERTIFICATE , cred should be
gnutls_certificate_credentials_t .
Returns: On success, GNUTLS_E_SUCCESS (0) is returned,
otherwise a negative error code is returned.
Next: Associating the credentials, Previous: Preparation, Up: How to use GnuTLS in applications [Contents][Index]