Memory-managed wrapper type.

Type class for types which can be safely cast to TlsConnection, for instance with toTlsConnection.

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

Used by TlsConnection implementations to emit the TlsConnection::acceptCertificate signal.

Since: 2.28

Gets conn's certificate, as set by tlsConnectionSetCertificate.

Since: 2.28

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 ByteArray buffer management and will be freed when the data is destroyed by byteArrayUnref. If data is Nothing, 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

Returns the name of the current TLS ciphersuite, or Nothing 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

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

Since: 2.30

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.30

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 Nothing. See tlsConnectionSetAdvertisedProtocols.

Since: 2.60

Gets conn's peer's certificate after the handshake has completed or failed. (It is not set during the emission of TlsConnection::acceptCertificate.)

Since: 2.28

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 TlsConnection::acceptCertificate.)

Since: 2.28

Returns the current TLS protocol version, which may be TlsProtocolVersionUnknown 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 TlsProtocolVersion.

Since: 2.70

Gets conn rehandshaking mode. See tlsConnectionSetRehandshakeMode for details.

Since: 2.28

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

Since: 2.28

Gets whether conn uses the system certificate database to verify peer certificates. See tlsConnectionSetUseSystemCertdb.

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), TlsConnection will handle this for you automatically when you try to send or receive data on the connection. You can call tlsConnectionHandshake 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 tlsConnectionHandshake 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.

When using a TlsConnection created by SocketClient, the SocketClient performs the initial handshake, so calling this function manually is not recommended.

TlsConnection::accept_certificate may be emitted during the handshake.

Since: 2.28

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

Since: 2.28

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

Since: 2.28

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 tlsConnectionGetNegotiatedProtocol to find the negotiated protocol after the handshake. Specifying Nothing 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

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

For a TlsClientConnection, 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 tlsClientConnectionGetAcceptedCas 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 tlsClientConnectionGetAcceptedCas will return non-Nothing.)

Since: 2.28

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 TlsConnection::acceptCertificate will always be emitted on client-side connections, unless that bit is not set in TlsClientConnection:validation-flags).

Since: 2.30

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.30

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.28

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 sometimes omitted. (TLS 1.1 explicitly allows this; in TLS 1.0 it is technically an error, but often done anyway.) You can use tlsConnectionSetRequireCloseNotify 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 SocketConnection, 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 iOStreamClose itself on conn, 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 TlsConnection:baseIoStream rather than closing conn itself, but note that this may only be done when no other operations are pending on conn or the base I/O stream.

Since: 2.28

Sets whether conn uses the system certificate database to verify peer certificates. This is True by default. If set to False, then peer certificate validation will always set the TlsCertificateFlagsUnknownCa error (meaning TlsConnection::acceptCertificate will always be emitted on client-side connections, unless that bit is not set in TlsClientConnection:validation-flags).

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

clear #advertisedProtocols

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

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

get tlsConnection #advertisedProtocols

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

set tlsConnection [ #advertisedProtocols := value ]

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

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

get tlsConnection #baseIoStream

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 tlsConnection #certificate

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

set tlsConnection [ #certificate := value ]

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

get tlsConnection #ciphersuiteName

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

clear #database

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 tlsConnection #database

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

set tlsConnection [ #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 tlsConnection #interaction

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

set tlsConnection [ #interaction := value ]

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

get tlsConnection #negotiatedProtocol

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

get tlsConnection #peerCertificate

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

get tlsConnection #peerCertificateErrors

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

get tlsConnection #protocolVersion

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 tlsConnection #rehandshakeMode

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

set tlsConnection [ #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 tlsConnection #requireCloseNotify

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

set tlsConnection [ #requireCloseNotify := value ]

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

Get the value of the “use-system-certdb” property. When overloading is enabled, this is equivalent to

get tlsConnection #useSystemCertdb

Set the value of the “use-system-certdb” property. When overloading is enabled, this is equivalent to

set tlsConnection [ #useSystemCertdb := value ]

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 TlsClientConnection: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 TlsServerConnection: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 TlsErrorBadCertificate, 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.28

Connect a signal handler for the acceptCertificate signal, to be run after the default handler. When overloading is enabled, this is equivalent to

after tlsConnection #acceptCertificate callback

By default the object invoking the signal is not passed to the callback. If you need to access it, you can use the implit ?self parameter. Note that this requires activating the ImplicitParams GHC extension.

Connect a signal handler for the acceptCertificate signal, to be run before the default handler. When overloading is enabled, this is equivalent to

on tlsConnection #acceptCertificate callback