Memory-managed wrapper type.

A convenience alias for Nothing :: Maybe DtlsConnection.

Type class for types which can be safely cast to DtlsConnection, for instance with toDtlsConnection.

Cast to DtlsConnection, for types for which this is known to be safe. For general casts, use castTo.

Close the DTLS connection. This is equivalent to calling dtlsConnectionShutdown to shut down both sides of the connection.

Closing a DtlsConnection 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 DtlsConnection:base-socket; that must be closed separately.

Once conn is closed, all other operations will return IOErrorEnumClosed. Closing a DtlsConnection 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 DtlsConnection may be left partially-closed and any pending untransmitted data may be lost. Call dtlsConnectionClose again to complete closing the DtlsConnection.

Since: 2.48

Asynchronously close the DTLS connection. See dtlsConnectionClose for more information.

Since: 2.48

Finish an asynchronous TLS close operation. See dtlsConnectionClose for more information.

Since: 2.48

Used by DtlsConnection implementations to emit the DtlsConnection::accept-certificate signal.

Since: 2.48

Gets conn's certificate, as set by dtlsConnectionSetCertificate.

Since: 2.48

Gets the certificate database that conn uses to verify peer certificates. See dtlsConnectionSetDatabase.

Since: 2.48

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 Nothing is returned, then no user interaction will occur for this connection.

Since: 2.48

Gets conn's peer's certificate after the handshake has completed. (It is not set during the emission of DtlsConnection::accept-certificate.)

Since: 2.48

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

Since: 2.48

Gets conn rehandshaking mode. See dtlsConnectionSetRehandshakeMode for details.

Since: 2.48

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

Since: 2.48

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 (or after sending a "STARTTLS"-type command) and may need to rehandshake later if the server requests it, DtlsConnection will handle this for you automatically when you try to send or receive data on the connection. However, you can call dtlsConnectionHandshake manually if you want to know for sure whether the initial handshake succeeded or failed (as opposed to just immediately trying to write to conn, in which case if it fails, it may not be possible to tell if it failed before or after completing the handshake).

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. However, you may call dtlsConnectionHandshake later on to renegotiate parameters (encryption methods, etc) with the client.

DtlsConnection::accept_certificate may be emitted during the handshake.

Since: 2.48

Asynchronously performs a TLS handshake on conn. See dtlsConnectionHandshake for more information.

Since: 2.48

Finish an asynchronous TLS handshake operation. See dtlsConnectionHandshake for more information.

Since: 2.48

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

For a DtlsClientConnection, this is optional. If a handshake fails with TlsErrorCertificateRequired, that means that the server requires a certificate, and if you try connecting again, you should call this method first. You can call dtlsClientConnectionGetAcceptedCas 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 dtlsClientConnectionGetAcceptedCas will return non-Nothing.)

Since: 2.48

Sets the certificate database that is used to verify peer certificates. This is set to the default database by default. See tlsBackendGetDefaultDatabase. If set to Nothing, then peer certificate validation will always set the TlsCertificateFlagsUnknownCa error (meaning DtlsConnection::accept-certificate will always be emitted on client-side connections, unless that bit is not set in DtlsClientConnection:validation-flags).

Since: 2.48

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 TlsInteraction. Nothing can also be provided if no user interaction should occur for this connection.

Since: 2.48

Sets how conn behaves with respect to rehandshaking requests.

TlsRehandshakeModeNever means that it will never agree to rehandshake after the initial handshake is complete. (For a client, this means it will refuse rehandshake requests from the server, and for a server, this means it will close the connection with an error if the client attempts to rehandshake.)

TlsRehandshakeModeSafely means that the connection will allow a rehandshake only if the other end of the connection supports the TLS renegotiation_info extension. This is the default behavior, but means that rehandshaking will not work against older implementations that do not support that extension.

TlsRehandshakeModeUnsafely means that the connection will allow rehandshaking even without the renegotiation_info extension. On the server side in particular, this is not recommended, since it leaves the server open to certain attacks. However, this mode is necessary if you need to allow renegotiation with older client software.

Since: 2.48

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 TlsErrorEof 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 dtlsConnectionSetRequireCloseNotify 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 DatagramBased, 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 dtlsConnectionCloseAsync 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 DtlsConnection:base-socket rather than closing conn itself.

Since: 2.48

Shut down part or all of a DTLS connection.

If shutdownRead is True then the receiving side of the connection is shut down, and further reading is disallowed. Subsequent calls to datagramBasedReceiveMessages will return IOErrorEnumClosed.

If shutdownWrite is True then the sending side of the connection is shut down, and further writing is disallowed. Subsequent calls to datagramBasedSendMessages will return IOErrorEnumClosed.

It is allowed for both shutdownRead and shutdownWrite to be TRUE — this is equivalent to calling dtlsConnectionClose.

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

Since: 2.48

Asynchronously shut down part or all of the DTLS connection. See dtlsConnectionShutdown for more information.

Since: 2.48

Finish an asynchronous TLS shutdown operation. See dtlsConnectionShutdown for more information.

Since: 2.48

Construct a GValueConstruct with valid value for the “base-socket” property. This is rarely needed directly, but it is used by new.

Get the value of the “base-socket” property. When overloading is enabled, this is equivalent to

get dtlsConnection #baseSocket

Construct a GValueConstruct with valid value for the “certificate” property. This is rarely needed directly, but it is used by new.

Get the value of the “certificate” property. When overloading is enabled, this is equivalent to

get dtlsConnection #certificate

Set the value of the “certificate” property. When overloading is enabled, this is equivalent to

set dtlsConnection [ #certificate := value ]

Construct a GValueConstruct with valid value for the “database” property. This is rarely needed directly, but it is used by new.

Get the value of the “database” property. When overloading is enabled, this is equivalent to

get dtlsConnection #database

Set the value of the “database” property. When overloading is enabled, this is equivalent to

set dtlsConnection [ #database := value ]

Set the value of the “interaction” property to Nothing. When overloading is enabled, this is equivalent to

clear #interaction

Construct a GValueConstruct with valid value for the “interaction” property. This is rarely needed directly, but it is used by new.

Get the value of the “interaction” property. When overloading is enabled, this is equivalent to

get dtlsConnection #interaction

Set the value of the “interaction” property. When overloading is enabled, this is equivalent to

set dtlsConnection [ #interaction := value ]

Get the value of the “peer-certificate” property. When overloading is enabled, this is equivalent to

get dtlsConnection #peerCertificate

Get the value of the “peer-certificate-errors” property. When overloading is enabled, this is equivalent to

get dtlsConnection #peerCertificateErrors

Construct a GValueConstruct with valid value for the “rehandshake-mode” property. This is rarely needed directly, but it is used by new.

Get the value of the “rehandshake-mode” property. When overloading is enabled, this is equivalent to

get dtlsConnection #rehandshakeMode

Set the value of the “rehandshake-mode” property. When overloading is enabled, this is equivalent to

set dtlsConnection [ #rehandshakeMode := value ]

Construct a GValueConstruct with valid value for the “require-close-notify” property. This is rarely needed directly, but it is used by new.

Get the value of the “require-close-notify” property. When overloading is enabled, this is equivalent to

get dtlsConnection #requireCloseNotify

Set the value of the “require-close-notify” property. When overloading is enabled, this is equivalent to

set dtlsConnection [ #requireCloseNotify := value ]

Type for the callback on the (unwrapped) C side.

Emitted during the TLS handshake after the peer certificate has been received. You can examine peerCert's certification path by calling tlsCertificateGetIssuer on it.

For a client-side connection, peerCert is the server's certificate, and the signal will only be emitted if the certificate was not acceptable according to conn's DtlsClientConnection: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 TlsErrorBadCertificate.

For a server-side connection, peerCert is the certificate presented by the client, if this was requested via the server's DtlsServerConnection: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 TlsErrorHandshake, 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.

Since: 2.48

Connect a signal handler for the “accept-certificate” signal, to be run after the default handler. When overloading is enabled, this is equivalent to

after dtlsConnection #acceptCertificate callback

Wrap the callback into a Closure.

Generate a function pointer callable from C code, from a C_DtlsConnectionAcceptCertificateCallback.

A convenience synonym for Nothing :: Maybe DtlsConnectionAcceptCertificateCallback.

Connect a signal handler for the “accept-certificate” signal, to be run before the default handler. When overloading is enabled, this is equivalent to

on dtlsConnection #acceptCertificate callback

Wrap a DtlsConnectionAcceptCertificateCallback into a C_DtlsConnectionAcceptCertificateCallback.