Gio.TlsConnection¶
- Subclasses:
None
Methods¶
- Inherited:
- Structs:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Virtual Methods¶
- Inherited:
|
|
|
|
|
|
|
|
|
Properties¶
- Inherited:
Name |
Type |
Flags |
Short Description |
---|---|---|---|
[ |
r/w |
||
r/w/co |
|||
r/w |
|||
r |
|||
r/w |
|||
r/w |
|||
r |
|||
r |
|||
r |
|||
r |
|||
d/r/w/c |
|
||
r/w/c |
|||
d/r/w/c |
|
Signals¶
- Inherited:
Name |
Short Description |
---|---|
Emitted during the TLS handshake after the peer certificate has been received. |
Fields¶
- Inherited:
Name |
Type |
Access |
Description |
---|---|---|---|
parent_instance |
r |
Class Details¶
- class Gio.TlsConnection(**kwargs)¶
- Bases:
- Abstract:
Yes
- Structure:
GTlsConnection
is the base TLS connection class type, which wraps a [class`Gio`.IOStream] and provides TLS encryption on top of it. Its subclasses, [iface`Gio`.TlsClientConnection] and [iface`Gio`.TlsServerConnection], implement client-side and server-side TLS, respectively.For DTLS (Datagram TLS) support, see [iface`Gio`.DtlsConnection].
New in version 2.28.
- emit_accept_certificate(peer_cert, errors)[source]¶
- Parameters:
peer_cert (
Gio.TlsCertificate
) – the peer’sGio.TlsCertificate
errors (
Gio.TlsCertificateFlags
) – the problems with peer_cert
- Returns:
True
if one of the signal handlers has returnedTrue
to accept peer_cert- Return type:
Used by
Gio.TlsConnection
implementations to emit theGio.TlsConnection
::accept-certificate
signal.New in version 2.28.
- get_certificate()[source]¶
- Returns:
self's certificate, or
None
- Return type:
Gets self's certificate, as set by
Gio.TlsConnection.set_certificate
().New in version 2.28.
- get_channel_binding_data(type)[source]¶
- Parameters:
type (
Gio.TlsChannelBindingType
) –Gio.TlsChannelBindingType
type of data to fetch- Raises:
- Returns:
True
on success,False
otherwise- data:
GLib.ByteArray
is filled with the binding data, orNone
- Return type:
Query the TLS backend for TLS channel binding data of type for self.
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
GLib.ByteArray
buffer management and will be freed when the data is destroyed byGLib.ByteArray.unref
(). If data isNone
, 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.New in version 2.66.
- get_ciphersuite_name()[source]¶
-
Returns the name of the current TLS ciphersuite, or
None
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.New in version 2.70.
- get_database()[source]¶
- Returns:
the certificate database that self uses or
None
- Return type:
Gets the certificate database that self uses to verify peer certificates. See
Gio.TlsConnection.set_database
().New in version 2.30.
- get_interaction()[source]¶
- Returns:
The interaction object.
- Return type:
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
None
is returned, then no user interaction will occur for this connection.New in version 2.30.
- get_negotiated_protocol()[source]¶
-
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 self's protocols, or the TLS backend does not support ALPN, then this will be
None
. SeeGio.TlsConnection.set_advertised_protocols
().New in version 2.60.
- get_peer_certificate()[source]¶
- Returns:
self's peer’s certificate, or
None
- Return type:
Gets self's peer’s certificate after the handshake has completed or failed. (It is not set during the emission of
Gio.TlsConnection
::accept-certificate
.)New in version 2.28.
- get_peer_certificate_errors()[source]¶
- Returns:
self's peer’s certificate errors
- Return type:
Gets the errors associated with validating self's peer’s certificate, after the handshake has completed or failed. (It is not set during the emission of
Gio.TlsConnection
::accept-certificate
.)See
Gio.TlsConnection
:peer-certificate-errors
for more information.New in version 2.28.
- get_protocol_version()[source]¶
- Returns:
The current TLS protocol version
- Return type:
Returns the current TLS protocol version, which may be
Gio.TlsProtocolVersion.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 recognizedGio.TlsProtocolVersion
.New in version 2.70.
- get_rehandshake_mode()[source]¶
- Returns:
- Return type:
Gets self rehandshaking mode. See
Gio.TlsConnection.set_rehandshake_mode
() for details.New in version 2.28.
Deprecated since version 2.60.: Changing the rehandshake mode is no longer required for compatibility. Also, rehandshaking has been removed from the TLS protocol in TLS 1.3.
- get_require_close_notify()[source]¶
-
Tests whether or not self expects a proper TLS close notification when the connection is closed. See
Gio.TlsConnection.set_require_close_notify
() for details.New in version 2.28.
- get_use_system_certdb()[source]¶
- Returns:
whether self uses the system certificate database
- Return type:
Gets whether self uses the system certificate database to verify peer certificates. See
Gio.TlsConnection.set_use_system_certdb
().Deprecated since version 2.30: Use
Gio.TlsConnection.get_database
() instead
- handshake(cancellable)[source]¶
- Parameters:
cancellable (
Gio.Cancellable
orNone
) – aGio.Cancellable
, orNone
- Raises:
- Returns:
success or failure
- Return type:
Attempts a TLS handshake on self.
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),
Gio.TlsConnection
will handle this for you automatically when you try to send or receive data on the connection. You can callGio.TlsConnection.handshake
() manually if you want to know whether the initial handshake succeeded or failed (as opposed to just immediately trying to use self 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
Gio.TlsConnection.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.When using a
Gio.TlsConnection
created byGio.SocketClient
, theGio.SocketClient
performs the initial handshake, so calling this function manually is not recommended.#GTlsConnection::accept_certificate may be emitted during the handshake.
New in version 2.28.
- handshake_async(io_priority, cancellable, callback, *user_data)[source]¶
- Parameters:
io_priority (
int
) – the I/O priority of the requestcancellable (
Gio.Cancellable
orNone
) – aGio.Cancellable
, orNone
callback (
Gio.AsyncReadyCallback
orNone
) – callback to call when the handshake is completeuser_data (
object
orNone
) – the data to pass to the callback function
Asynchronously performs a TLS handshake on self. See
Gio.TlsConnection.handshake
() for more information.New in version 2.28.
- handshake_finish(result)[source]¶
- Parameters:
result (
Gio.AsyncResult
) – aGio.AsyncResult
.- Raises:
- Returns:
True
on success,False
on failure, in which case error will be set.- Return type:
Finish an asynchronous TLS handshake operation. See
Gio.TlsConnection.handshake
() for more information.New in version 2.28.
- set_advertised_protocols(protocols)[source]¶
- Parameters:
protocols ([
str
] orNone
) – aNone
-terminated array of ALPN protocol names (eg, “http/1.1”, “h2”), orNone
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
Gio.TlsConnection.get_negotiated_protocol
() to find the negotiated protocol after the handshake. SpecifyingNone
for the the value of protocols will disable ALPN negotiation.See IANA TLS ALPN Protocol IDs for a list of registered protocol IDs.
New in version 2.60.
- set_certificate(certificate)[source]¶
- Parameters:
certificate (
Gio.TlsCertificate
) – the certificate to use for self
This sets the certificate that self will present to its peer during the TLS handshake. For a
Gio.TlsServerConnection
, it is mandatory to set this, and that will normally be done at construct time.For a
Gio.TlsClientConnection
, this is optional. If a handshake fails withGio.TlsError.CERTIFICATE_REQUIRED
, that means that the server requires a certificate, and if you try connecting again, you should call this method first. You can callGio.TlsClientConnection.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
Gio.TlsClientConnection.get_accepted_cas
() will return non-None
.)New in version 2.28.
- set_database(database)[source]¶
- Parameters:
database (
Gio.TlsDatabase
orNone
) – aGio.TlsDatabase
Sets the certificate database that is used to verify peer certificates. This is set to the default database by default. See
Gio.TlsBackend.get_default_database
(). If set toNone
, then peer certificate validation will always set theGio.TlsCertificateFlags.UNKNOWN_CA
error (meaningGio.TlsConnection
::accept-certificate
will always be emitted on client-side connections, unless that bit is not set inGio.TlsClientConnection
:validation-flags
).There are nonintuitive security implications when using a non-default database. See
Gio.TlsConnection
:database
for details.New in version 2.30.
- set_interaction(interaction)[source]¶
- Parameters:
interaction (
Gio.TlsInteraction
orNone
) – an interaction object, orNone
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
Gio.TlsInteraction
.None
can also be provided if no user interaction should occur for this connection.New in version 2.30.
- set_rehandshake_mode(mode)[source]¶
- Parameters:
mode (
Gio.TlsRehandshakeMode
) – the rehandshaking 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.
New in version 2.28.
Deprecated since version 2.60.: Changing the rehandshake mode is no longer required for compatibility. Also, rehandshaking has been removed from the TLS protocol in TLS 1.3.
- set_require_close_notify(require_close_notify)[source]¶
- Parameters:
require_close_notify (
bool
) – whether or not to require close notification
Sets whether or not self expects a proper TLS close notification before the connection is closed. If this is
True
(the default), then self will expect to receive a TLS close notification from its peer before the connection is closed, and will return aGio.TlsError.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 sometimes omitted. (TLS 1.1 explicitly allows this; in TLS 1.0 it is technically an error, but often done anyway.) You can use
Gio.TlsConnection.set_require_close_notify
() to tell self to allow an “unannounced” connection close, in which case the close will show up as a 0-length read, as in a non-TLSGio.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
Gio.IOStream.close
() itself on self, 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 self'sGio.TlsConnection
:base-io-stream
rather than closing self itself, but note that this may only be done when no other operations are pending on self or the base I/O stream.New in version 2.28.
- set_use_system_certdb(use_system_certdb)[source]¶
- Parameters:
use_system_certdb (
bool
) – whether to use the system certificate database
Sets whether self uses the system certificate database to verify peer certificates. This is
True
by default. If set toFalse
, then peer certificate validation will always set theGio.TlsCertificateFlags.UNKNOWN_CA
error (meaningGio.TlsConnection
::accept-certificate
will always be emitted on client-side connections, unless that bit is not set inGio.TlsClientConnection
:validation-flags
).Deprecated since version 2.30: Use
Gio.TlsConnection.set_database
() instead
- do_accept_certificate(peer_cert, errors) virtual¶
- Parameters:
peer_cert (
Gio.TlsCertificate
) –errors (
Gio.TlsCertificateFlags
) –
- Return type:
Check whether to accept a certificate.
- do_get_binding_data(type, data) virtual¶
- Parameters:
type (
Gio.TlsChannelBindingType
) –data (
bytes
) –
- Return type:
Retrieve TLS channel binding data
New in version 2.66.
- do_get_negotiated_protocol() virtual¶
-
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
None
. SeeGio.TlsConnection.set_advertised_protocols
().New in version 2.60.
- do_handshake(cancellable) virtual¶
- Parameters:
cancellable (
Gio.Cancellable
orNone
) – aGio.Cancellable
, orNone
- Returns:
success or failure
- Return type:
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),
Gio.TlsConnection
will handle this for you automatically when you try to send or receive data on the connection. You can callGio.TlsConnection.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
Gio.TlsConnection.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.When using a
Gio.TlsConnection
created byGio.SocketClient
, theGio.SocketClient
performs the initial handshake, so calling this function manually is not recommended.#GTlsConnection::accept_certificate may be emitted during the handshake.
New in version 2.28.
- do_handshake_async(io_priority, cancellable, callback, *user_data) virtual¶
- Parameters:
io_priority (
int
) – the I/O priority of the requestcancellable (
Gio.Cancellable
orNone
) – aGio.Cancellable
, orNone
callback (
Gio.AsyncReadyCallback
orNone
) – callback to call when the handshake is completeuser_data (
object
orNone
) – the data to pass to the callback function
Asynchronously performs a TLS handshake on conn. See
Gio.TlsConnection.handshake
() for more information.New in version 2.28.
- do_handshake_finish(result) virtual¶
- Parameters:
result (
Gio.AsyncResult
) – aGio.AsyncResult
.- Returns:
True
on success,False
on failure, in which case error will be set.- Return type:
Finish an asynchronous TLS handshake operation. See
Gio.TlsConnection.handshake
() for more information.New in version 2.28.
Signal Details¶
- Gio.TlsConnection.signals.accept_certificate(tls_connection, peer_cert, errors)¶
- Signal Name:
accept-certificate
- Flags:
- Parameters:
tls_connection (
Gio.TlsConnection
) – The object which received the signalpeer_cert (
Gio.TlsCertificate
) – the peer’sGio.TlsCertificate
errors (
Gio.TlsCertificateFlags
) – the problems with peer_cert.
- Returns:
True
to accept peer_cert (which will also immediately end the signal emission).False
to allow the signal emission to continue, which will cause the handshake to fail if no one else overrides it.- Return type:
Emitted during the TLS handshake after the peer certificate has been received. You can examine peer_cert's certification path by calling
Gio.TlsCertificate.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 #GTlsClientConnection: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 withGio.TlsError.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
Gio.TlsCertificateFlags.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 #GTlsServerConnection: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 aGio.TlsError.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 returnTrue
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.
New in version 2.28.
Property Details¶
- Gio.TlsConnection.props.advertised_protocols¶
-
The list of application-layer protocols that the connection advertises that it is willing to speak. See
Gio.TlsConnection.set_advertised_protocols
().New in version 2.60.
- Gio.TlsConnection.props.base_io_stream¶
- Name:
base-io-stream
- Type:
- Default Value:
- Flags:
The
Gio.IOStream
that the connection wraps. The connection holds a reference to this stream, and may run operations on the stream from other threads throughout its lifetime. Consequently, after theGio.IOStream
has been constructed, application code may only run its own operations on this stream when noGio.IOStream
operations are running.New in version 2.28.
- Gio.TlsConnection.props.certificate¶
- Name:
certificate
- Type:
- Default Value:
- Flags:
The connection’s certificate; see
Gio.TlsConnection.set_certificate
().New in version 2.28.
- Gio.TlsConnection.props.ciphersuite_name¶
-
The name of the TLS ciphersuite in use. See
Gio.TlsConnection.get_ciphersuite_name
().New in version 2.70.
- Gio.TlsConnection.props.database¶
- Name:
database
- Type:
- Default Value:
- Flags:
The certificate database to use when verifying this TLS connection. If no certificate database is set, then the default database will be used. See
Gio.TlsBackend.get_default_database
().When using a non-default database,
Gio.TlsConnection
must fall back to using theGio.TlsDatabase
to perform certificate verification usingGio.TlsDatabase.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 ownGio.TlsDatabase
that just wraps the defaultGio.TlsDatabase
, you might expect that you have not changed anything, but this is not true because you may have altered the behavior ofGio.TlsConnection
by causing it to useGio.TlsDatabase.verify_chain
(). See the documentation ofGio.TlsDatabase.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.New in version 2.30.
- Gio.TlsConnection.props.interaction¶
- Name:
interaction
- Type:
- Default Value:
- Flags:
A
Gio.TlsInteraction
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.New in version 2.30.
- Gio.TlsConnection.props.negotiated_protocol¶
-
The application-layer protocol negotiated during the TLS handshake. See
Gio.TlsConnection.get_negotiated_protocol
().New in version 2.60.
- Gio.TlsConnection.props.peer_certificate¶
- Name:
peer-certificate
- Type:
- Default Value:
- Flags:
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
Gio.TlsConnection
::accept-certificate
.(You can watch for a
GObject.Object
::notify
signal on this property to detect when a handshake has occurred.)New in version 2.28.
- Gio.TlsConnection.props.peer_certificate_errors¶
- Name:
peer-certificate-errors
- Type:
- Default Value:
- Flags:
The errors noticed while verifying
Gio.TlsConnection
:peer-certificate
. Normally this should be 0, but it may not be ifGio.TlsClientConnection
:validation-flags
is notGio.TlsCertificateFlags.VALIDATE_ALL
, or ifGio.TlsConnection
::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
Gio.TlsCertificateFlags.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.New in version 2.28.
- Gio.TlsConnection.props.protocol_version¶
- Name:
protocol-version
- Type:
- Default Value:
- Flags:
The TLS protocol version in use. See
Gio.TlsConnection.get_protocol_version
().New in version 2.70.
- Gio.TlsConnection.props.rehandshake_mode¶
- Name:
rehandshake-mode
- Type:
- Default Value:
- Flags:
The rehandshaking mode. See
Gio.TlsConnection.set_rehandshake_mode
().New in version 2.28.
Deprecated since version 2.60: The rehandshake mode is ignored.
- Gio.TlsConnection.props.require_close_notify¶
-
Whether or not proper TLS close notification is required. See
Gio.TlsConnection.set_require_close_notify
().New in version 2.28.
- Gio.TlsConnection.props.use_system_certdb¶
- Name:
use-system-certdb
- Type:
- Default Value:
- Flags:
Whether or not the system certificate database will be used to verify peer certificates. See
Gio.TlsConnection.set_use_system_certdb
().Deprecated since version 2.30: Use
Gio.TlsConnection
:database
instead