g_dtls_connection_set_certificate ()

void
g_dtls_connection_set_certificate (GDtlsConnection *conn,
                                   GTlsCertificate *certificate);

This sets the certificate that conn will present to its peer during the TLS handshake. For a GDtlsServerConnection, it is mandatory to set this, and that will normally be done at construct time.

For a GDtlsClientConnection, this is optional. If a handshake fails with G_TLS_ERROR_CERTIFICATE_REQUIRED, that means that the server requires a certificate, and if you try connecting again, you should call this method first. You can call g_dtls_client_connection_get_accepted_cas() on the failed connection to get a list of Certificate Authorities that the server will accept certificates from.

(It is also possible that a server will allow the connection with or without a certificate; in that case, if you don't provide a certificate, you can tell that the server requested one by the fact that g_dtls_client_connection_get_accepted_cas() will return non-NULL.)

Since: 2.48

g_dtls_connection_get_certificate ()

GTlsCertificate *
g_dtls_connection_get_certificate (GDtlsConnection *conn);

Gets conn 's certificate, as set by g_dtls_connection_set_certificate().

Since: 2.48

g_dtls_connection_get_peer_certificate ()

GTlsCertificate *
g_dtls_connection_get_peer_certificate
                               (GDtlsConnection *conn);

Gets conn 's peer's certificate after the handshake has completed or failed. (It is not set during the emission of “accept-certificate”.)

Since: 2.48

g_dtls_connection_get_peer_certificate_errors ()

GTlsCertificateFlags
g_dtls_connection_get_peer_certificate_errors
                               (GDtlsConnection *conn);

Gets the errors associated with validating conn 's peer's certificate, after the handshake has completed or failed. (It is not set during the emission of “accept-certificate”.)

Since: 2.48

g_dtls_connection_get_channel_binding_data ()

gboolean
g_dtls_connection_get_channel_binding_data
                               (GDtlsConnection *conn,
                                GTlsChannelBindingType type,
                                GByteArray *data,
                                GError **error);

Query the TLS backend for TLS channel binding data of type for conn .

This call retrieves TLS channel binding data as specified in RFC 5056, RFC 5929, and related RFCs. The binding data is returned in data . The data is resized by the callee using GByteArray buffer management and will be freed when the data is destroyed by g_byte_array_unref(). If data is NULL, it will only check whether TLS backend is able to fetch the data (e.g. whether type is supported by the TLS backend). It does not guarantee that the data will be available though. That could happen if TLS connection does not support type or the binding data is not available yet due to additional negotiation or input required.

Since: 2.66

g_dtls_connection_set_require_close_notify ()

void
g_dtls_connection_set_require_close_notify
                               (GDtlsConnection *conn,
                                gboolean require_close_notify);

Sets whether or not conn expects a proper TLS close notification before the connection is closed. If this is TRUE (the default), then conn will expect to receive a TLS close notification from its peer before the connection is closed, and will return a G_TLS_ERROR_EOF error if the connection is closed without proper notification (since this may indicate a network error, or man-in-the-middle attack).

In some protocols, the application will know whether or not the connection was closed cleanly based on application-level data (because the application-level data includes a length field, or is somehow self-delimiting); in this case, the close notify is redundant and may be omitted. You can use g_dtls_connection_set_require_close_notify() to tell conn to allow an "unannounced" connection close, in which case the close will show up as a 0-length read, as in a non-TLS GDatagramBased, and it is up to the application to check that the data has been fully received.

Note that this only affects the behavior when the peer closes the connection; when the application calls g_dtls_connection_close_async() on conn itself, this will send a close notification regardless of the setting of this property. If you explicitly want to do an unclean close, you can close conn 's “base-socket” rather than closing conn itself.

Since: 2.48

g_dtls_connection_get_require_close_notify ()

gboolean
g_dtls_connection_get_require_close_notify
                               (GDtlsConnection *conn);

Tests whether or not conn expects a proper TLS close notification when the connection is closed. See g_dtls_connection_set_require_close_notify() for details.

Since: 2.48

g_dtls_connection_set_rehandshake_mode ()

void
g_dtls_connection_set_rehandshake_mode
                               (GDtlsConnection *conn,
                                GTlsRehandshakeMode mode);

Since GLib 2.64, changing the rehandshake mode is no longer supported and will have no effect. With TLS 1.3, rehandshaking has been removed from the TLS protocol, replaced by separate post-handshake authentication and rekey operations.

Since: 2.48

g_dtls_connection_get_rehandshake_mode ()

GTlsRehandshakeMode
g_dtls_connection_get_rehandshake_mode
                               (GDtlsConnection *conn);

Gets conn rehandshaking mode. See g_dtls_connection_set_rehandshake_mode() for details.

Since: 2.48

g_dtls_connection_set_advertised_protocols ()

void
g_dtls_connection_set_advertised_protocols
                               (GDtlsConnection *conn,
                                const gchar * const *protocols);

Sets the list of application-layer protocols to advertise that the caller is willing to speak on this connection. The Application-Layer Protocol Negotiation (ALPN) extension will be used to negotiate a compatible protocol with the peer; use g_dtls_connection_get_negotiated_protocol() to find the negotiated protocol after the handshake. Specifying NULL for the the value of protocols will disable ALPN negotiation.

See IANA TLS ALPN Protocol IDs for a list of registered protocol IDs.

Since: 2.60

g_dtls_connection_get_negotiated_protocol ()

const gchar *
g_dtls_connection_get_negotiated_protocol
                               (GDtlsConnection *conn);

Gets the name of the application-layer protocol negotiated during the handshake.

If the peer did not use the ALPN extension, or did not advertise a protocol that matched one of conn 's protocols, or the TLS backend does not support ALPN, then this will be NULL. See g_dtls_connection_set_advertised_protocols().

Since: 2.60

g_dtls_connection_get_database ()

GTlsDatabase *
g_dtls_connection_get_database (GDtlsConnection *conn);

Gets the certificate database that conn uses to verify peer certificates. See g_dtls_connection_set_database().

Since: 2.48

g_dtls_connection_set_database ()

void
g_dtls_connection_set_database (GDtlsConnection *conn,
                                GTlsDatabase *database);

Sets the certificate database that is used to verify peer certificates. This is set to the default database by default. See g_tls_backend_get_default_database(). If set to NULL, then peer certificate validation will always set the G_TLS_CERTIFICATE_UNKNOWN_CA error (meaning “accept-certificate” will always be emitted on client-side connections, unless that bit is not set in “validation-flags”).

There are nonintuitive security implications when using a non-default database. See “database” for details.

Since: 2.48

g_dtls_connection_get_interaction ()

GTlsInteraction *
g_dtls_connection_get_interaction (GDtlsConnection *conn);

Get the object that will be used to interact with the user. It will be used for things like prompting the user for passwords. If NULL is returned, then no user interaction will occur for this connection.

Since: 2.48

g_dtls_connection_set_interaction ()

void
g_dtls_connection_set_interaction (GDtlsConnection *conn,
                                   GTlsInteraction *interaction);

Set the object that will be used to interact with the user. It will be used for things like prompting the user for passwords.

The interaction argument will normally be a derived subclass of GTlsInteraction. NULL can also be provided if no user interaction should occur for this connection.

Since: 2.48

g_dtls_connection_get_protocol_version ()

GTlsProtocolVersion
g_dtls_connection_get_protocol_version
                               (GDtlsConnection *conn);

Returns the current DTLS protocol version, which may be G_TLS_PROTOCOL_VERSION_UNKNOWN if the connection has not handshaked, or has been closed, or if the TLS backend has implemented a protocol version that is not a recognized GTlsProtocolVersion.

Since: 2.70

g_dtls_connection_get_ciphersuite_name ()

gchar *
g_dtls_connection_get_ciphersuite_name
                               (GDtlsConnection *conn);

Returns the name of the current DTLS ciphersuite, or NULL if the connection has not handshaked or has been closed. Beware that the TLS backend may use any of multiple different naming conventions, because OpenSSL and GnuTLS have their own ciphersuite naming conventions that are different from each other and different from the standard, IANA- registered ciphersuite names. The ciphersuite name is intended to be displayed to the user for informative purposes only, and parsing it is not recommended.

Since: 2.70

g_dtls_connection_handshake ()

gboolean
g_dtls_connection_handshake (GDtlsConnection *conn,
                             GCancellable *cancellable,
                             GError **error);

Attempts a TLS handshake on conn .

On the client side, it is never necessary to call this method; although the connection needs to perform a handshake after connecting, GDtlsConnection will handle this for you automatically when you try to send or receive data on the connection. You can call g_dtls_connection_handshake() manually if you want to know whether the initial handshake succeeded or failed (as opposed to just immediately trying to use conn to read or write, in which case, if it fails, it may not be possible to tell if it failed before or after completing the handshake), but beware that servers may reject client authentication after the handshake has completed, so a successful handshake does not indicate the connection will be usable.

Likewise, on the server side, although a handshake is necessary at the beginning of the communication, you do not need to call this function explicitly unless you want clearer error reporting.

Previously, calling g_dtls_connection_handshake() after the initial handshake would trigger a rehandshake; however, this usage was deprecated in GLib 2.60 because rehandshaking was removed from the TLS protocol in TLS 1.3. Since GLib 2.64, calling this function after the initial handshake will no longer do anything.

“accept_certificate” may be emitted during the handshake.

Since: 2.48

g_dtls_connection_handshake_async ()

void
g_dtls_connection_handshake_async (GDtlsConnection *conn,
                                   int io_priority,
                                   GCancellable *cancellable,
                                   GAsyncReadyCallback callback,
                                   gpointer user_data);

Asynchronously performs a TLS handshake on conn . See g_dtls_connection_handshake() for more information.

Since: 2.48

g_dtls_connection_handshake_finish ()

gboolean
g_dtls_connection_handshake_finish (GDtlsConnection *conn,
                                    GAsyncResult *result,
                                    GError **error);

Finish an asynchronous TLS handshake operation. See g_dtls_connection_handshake() for more information.

Since: 2.48

g_dtls_connection_shutdown ()

gboolean
g_dtls_connection_shutdown (GDtlsConnection *conn,
                            gboolean shutdown_read,
                            gboolean shutdown_write,
                            GCancellable *cancellable,
                            GError **error);

Shut down part or all of a DTLS connection.

If shutdown_read is TRUE then the receiving side of the connection is shut down, and further reading is disallowed. Subsequent calls to g_datagram_based_receive_messages() will return G_IO_ERROR_CLOSED.

If shutdown_write is TRUE then the sending side of the connection is shut down, and further writing is disallowed. Subsequent calls to g_datagram_based_send_messages() will return G_IO_ERROR_CLOSED.

It is allowed for both shutdown_read and shutdown_write to be TRUE — this is equivalent to calling g_dtls_connection_close().

If cancellable is cancelled, the GDtlsConnection may be left partially-closed and any pending untransmitted data may be lost. Call g_dtls_connection_shutdown() again to complete closing the GDtlsConnection.

Since: 2.48

g_dtls_connection_shutdown_async ()

void
g_dtls_connection_shutdown_async (GDtlsConnection *conn,
                                  gboolean shutdown_read,
                                  gboolean shutdown_write,
                                  int io_priority,
                                  GCancellable *cancellable,
                                  GAsyncReadyCallback callback,
                                  gpointer user_data);

Asynchronously shut down part or all of the DTLS connection. See g_dtls_connection_shutdown() for more information.

Since: 2.48

g_dtls_connection_shutdown_finish ()

gboolean
g_dtls_connection_shutdown_finish (GDtlsConnection *conn,
                                   GAsyncResult *result,
                                   GError **error);

Finish an asynchronous TLS shutdown operation. See g_dtls_connection_shutdown() for more information.

Since: 2.48

g_dtls_connection_close ()

gboolean
g_dtls_connection_close (GDtlsConnection *conn,
                         GCancellable *cancellable,
                         GError **error);

Close the DTLS connection. This is equivalent to calling g_dtls_connection_shutdown() to shut down both sides of the connection.

Closing a GDtlsConnection waits for all buffered but untransmitted data to be sent before it completes. It then sends a close_notify DTLS alert to the peer and may wait for a close_notify to be received from the peer. It does not close the underlying “base-socket”; that must be closed separately.

Once conn is closed, all other operations will return G_IO_ERROR_CLOSED. Closing a GDtlsConnection multiple times will not return an error.

GDtlsConnections will be automatically closed when the last reference is dropped, but you might want to call this function to make sure resources are released as early as possible.

If cancellable is cancelled, the GDtlsConnection may be left partially-closed and any pending untransmitted data may be lost. Call g_dtls_connection_close() again to complete closing the GDtlsConnection.

Since: 2.48

g_dtls_connection_close_async ()

void
g_dtls_connection_close_async (GDtlsConnection *conn,
                               int io_priority,
                               GCancellable *cancellable,
                               GAsyncReadyCallback callback,
                               gpointer user_data);

Asynchronously close the DTLS connection. See g_dtls_connection_close() for more information.

Since: 2.48

g_dtls_connection_close_finish ()

gboolean
g_dtls_connection_close_finish (GDtlsConnection *conn,
                                GAsyncResult *result,
                                GError **error);

Finish an asynchronous TLS close operation. See g_dtls_connection_close() for more information.

Since: 2.48

g_dtls_connection_emit_accept_certificate ()

gboolean
g_dtls_connection_emit_accept_certificate
                               (GDtlsConnection *conn,
                                GTlsCertificate *peer_cert,
                                GTlsCertificateFlags errors);

Used by GDtlsConnection implementations to emit the “accept-certificate” signal.

Since: 2.48

GDtlsConnection

typedef struct _GDtlsConnection GDtlsConnection;

Abstract base class for the backend-specific GDtlsClientConnection and GDtlsServerConnection types.

Since: 2.48

The “advertised-protocols” property

  “advertised-protocols”     GStrv

The list of application-layer protocols that the connection advertises that it is willing to speak. See g_dtls_connection_set_advertised_protocols().

[nullable]

Owner: GDtlsConnection

Flags: Read / Write

Since: 2.60

The “base-socket” property

  “base-socket”              GDatagramBased *

The GDatagramBased that the connection wraps. Note that this may be any implementation of GDatagramBased, not just a GSocket.

Owner: GDtlsConnection

Flags: Read / Write / Construct Only

Since: 2.48

The “certificate” property

  “certificate”              GTlsCertificate *

The connection's certificate; see g_dtls_connection_set_certificate().

Owner: GDtlsConnection

Flags: Read / Write

Since: 2.48

The “ciphersuite-name” property

  “ciphersuite-name”         char *

The name of the DTLS ciphersuite in use. See g_dtls_connection_get_ciphersuite_name().

[nullable]

Owner: GDtlsConnection

Flags: Read

Default value: NULL

Since: 2.70

The “database” property

  “database”                 GTlsDatabase *

The certificate database to use when verifying this TLS connection. If no certificate database is set, then the default database will be used. See g_tls_backend_get_default_database().

When using a non-default database, GDtlsConnection must fall back to using the GTlsDatabase to perform certificate verification using g_tls_database_verify_chain(), which means certificate verification will not be able to make use of TLS session context. This may be less secure. For example, if you create your own GTlsDatabase that just wraps the default GTlsDatabase, you might expect that you have not changed anything, but this is not true because you may have altered the behavior of GDtlsConnection by causing it to use g_tls_database_verify_chain(). See the documentation of g_tls_database_verify_chain() for more details on specific security checks that may not be performed. Accordingly, setting a non-default database is discouraged except for specialty applications with unusual security requirements.

[nullable]

Owner: GDtlsConnection

Flags: Read / Write

Since: 2.48

The “interaction” property

  “interaction”              GTlsInteraction *

A GTlsInteraction object to be used when the connection or certificate database need to interact with the user. This will be used to prompt the user for passwords where necessary.

[nullable]

Owner: GDtlsConnection

Flags: Read / Write

Since: 2.48

The “negotiated-protocol” property

  “negotiated-protocol”      char *

The application-layer protocol negotiated during the TLS handshake. See g_dtls_connection_get_negotiated_protocol().

Owner: GDtlsConnection

Flags: Read

Default value: NULL

Since: 2.60

The “peer-certificate” property

  “peer-certificate”         GTlsCertificate *

The connection's peer's certificate, after the TLS handshake has completed or failed. Note in particular that this is not yet set during the emission of “accept-certificate”.

(You can watch for a “notify” signal on this property to detect when a handshake has occurred.)

[nullable]

Owner: GDtlsConnection

Flags: Read

Since: 2.48

The “peer-certificate-errors” property

  “peer-certificate-errors”  GTlsCertificateFlags

The errors noticed while verifying “peer-certificate”. Normally this should be 0, but it may not be if “validation-flags” is not G_TLS_CERTIFICATE_VALIDATE_ALL, or if “accept-certificate” overrode the default behavior.

GLib guarantees that if certificate verification fails, at least one error will be set, but it does not guarantee that all possible errors will be set. Accordingly, you may not safely decide to ignore any particular type of error. For example, it would be incorrect to mask G_TLS_CERTIFICATE_EXPIRED if you want to allow expired certificates, because this could potentially be the only error flag set even if other problems exist with the certificate.

Owner: GDtlsConnection

Flags: Read

Since: 2.48

The “protocol-version” property

  “protocol-version”         GTlsProtocolVersion

The DTLS protocol version in use. See g_dtls_connection_get_protocol_version().

Owner: GDtlsConnection

Flags: Read

Default value: G_TLS_PROTOCOL_VERSION_UNKNOWN

Since: 2.70

The “rehandshake-mode” property

  “rehandshake-mode”         GTlsRehandshakeMode

The rehandshaking mode. See g_dtls_connection_set_rehandshake_mode().

Owner: GDtlsConnection

Flags: Read / Write / Construct

Default value: G_TLS_REHANDSHAKE_NEVER

Since: 2.48

The “require-close-notify” property

  “require-close-notify”     gboolean

Whether or not proper TLS close notification is required. See g_dtls_connection_set_require_close_notify().

Owner: GDtlsConnection

Flags: Read / Write / Construct

Default value: TRUE

Since: 2.48

The “accept-certificate” signal

gboolean
user_function (GDtlsConnection     *conn,
               GTlsCertificate     *peer_cert,
               GTlsCertificateFlags errors,
               gpointer             user_data)

Emitted during the TLS handshake after the peer certificate has been received. You can examine peer_cert 's certification path by calling g_tls_certificate_get_issuer() on it.

For a client-side connection, peer_cert is the server's certificate, and the signal will only be emitted if the certificate was not acceptable according to conn 's “validation_flags”. If you would like the certificate to be accepted despite errors , return TRUE from the signal handler. Otherwise, if no handler accepts the certificate, the handshake will fail with G_TLS_ERROR_BAD_CERTIFICATE.

GLib guarantees that if certificate verification fails, this signal will be emitted with at least one error will be set in errors , but it does not guarantee that all possible errors will be set. Accordingly, you may not safely decide to ignore any particular type of error. For example, it would be incorrect to ignore G_TLS_CERTIFICATE_EXPIRED if you want to allow expired certificates, because this could potentially be the only error flag set even if other problems exist with the certificate.

For a server-side connection, peer_cert is the certificate presented by the client, if this was requested via the server's “authentication_mode”. On the server side, the signal is always emitted when the client presents a certificate, and the certificate will only be accepted if a handler returns TRUE.

Note that if this signal is emitted as part of asynchronous I/O in the main thread, then you should not attempt to interact with the user before returning from the signal handler. If you want to let the user decide whether or not to accept the certificate, you would have to return FALSE from the signal handler on the first attempt, and then after the connection attempt returns a G_TLS_ERROR_BAD_CERTIFICATE, you can interact with the user, and if the user decides to accept the certificate, remember that fact, create a new connection, and return TRUE from the signal handler the next time.

If you are doing I/O in another thread, you do not need to worry about this, and can simply block in the signal handler until the UI thread returns an answer.

Flags: Run Last

Since: 2.48