| Top | |
|
|
|
| #define | G_TLS_ERROR |
| enum | GTlsError |
| #define | G_TLS_CHANNEL_BINDING_ERROR |
| enum | GTlsChannelBindingError |
| enum | GTlsAuthenticationMode |
| enum | GTlsCertificateFlags |
| enum | GTlsProtocolVersion |
GEnum
├── GTlsAuthenticationMode
├── GTlsChannelBindingError
├── GTlsError
╰── GTlsProtocolVersion
GFlags
╰── GTlsCertificateFlags
GTlsConnection and related classes provide TLS (Transport Layer Security, previously known as SSL, Secure Sockets Layer) support for gio-based network streams.
GDtlsConnection and related classes provide DTLS (Datagram TLS) support for GIO-based network sockets, using the GDatagramBased interface. The TLS and DTLS APIs are almost identical, except TLS is stream-based and DTLS is datagram-based. They share certificate and backend infrastructure.
In the simplest case, for a client TLS connection, you can just set the “tls” flag on a GSocketClient, and then any connections created by that client will have TLS negotiated automatically, using appropriate default settings, and rejecting any invalid or self-signed certificates (unless you change that default by setting the “tls-validation-flags” property). The returned object will be a GTcpWrapperConnection, which wraps the underlying GTlsClientConnection.
For greater control, you can create your own GTlsClientConnection, wrapping a GSocketConnection (or an arbitrary GIOStream with pollable input and output streams) and then connect to its signals, such as “accept-certificate”, before starting the handshake.
Server-side TLS is similar, using GTlsServerConnection. At the moment, there is no support for automatically wrapping server-side connections in the way GSocketClient does for client-side connections.
#define G_TLS_ERROR (g_tls_error_quark ())
Error domain for TLS. Errors in this domain will be from the GTlsError enumeration. See GError for more information on error domains.
An error code used with G_TLS_ERROR in a GError returned from a
TLS-related routine.
|
No TLS provider is available |
||
|
Miscellaneous TLS error |
||
|
The certificate presented could not be parsed or failed validation. |
||
|
The TLS handshake failed because the peer does not seem to be a TLS server. |
||
|
The TLS handshake failed because the peer's certificate was not acceptable. |
||
|
The TLS handshake failed because
the server requested a client-side certificate, but none was
provided. See |
||
|
The TLS connection was closed without proper
notice, which may indicate an attack. See
|
||
|
The TLS handshake failed because the client sent the fallback SCSV, indicating a protocol downgrade attack. Since: 2.60 |
||
|
The certificate failed to load because a password was incorrect. Since: 2.72 |
Since: 2.28
#define G_TLS_CHANNEL_BINDING_ERROR (g_tls_channel_binding_error_quark ())
Error domain for TLS channel binding. Errors in this domain will be from the GTlsChannelBindingError enumeration. See GError for more information on error domains.
Since: 2.66
An error code used with G_TLS_CHANNEL_BINDING_ERROR in a GError to
indicate a TLS channel binding retrieval error.
|
Either entire binding retrieval facility or specific binding type is not implemented in the TLS backend. |
||
|
The handshake is not yet complete on the connection which is a strong requirement for any existing binding type. |
||
|
Handshake is complete but binding data is not available. That normally indicates the TLS implementation failed to provide the binding data. For example, some implementations do not provide a peer certificate for resumed connections. |
||
|
Binding type is not supported
on the current connection. This error could be triggered when requesting
|
||
|
Any other backend error preventing binding data retrieval. |
Since: 2.66
The client authentication mode for a GTlsServerConnection.
Since: 2.28
A set of flags describing TLS certification validation. This can be used to describe why a particular certificate was rejected (for example, in “accept-certificate”).
GLib guarantees that if certificate verification fails, at least one
flag will be set, but it does not guarantee that all possible flags
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.
|
The signing certificate authority is not known. |
||
|
The certificate does not match the expected identity of the site that it was retrieved from. |
||
|
The certificate's activation time is still in the future |
||
|
The certificate has expired |
||
|
The certificate has been revoked according to the GTlsConnection's certificate revocation list. |
||
|
The certificate's algorithm is considered insecure. |
||
|
Some other error occurred validating the certificate |
||
|
the combination of all of the above flags |
Since: 2.28
The TLS or DTLS protocol version used by a GTlsConnection or
GDtlsConnection. The integer values of these versions are sequential
to ensure newer known protocol versions compare greater than older
known versions. Any known DTLS protocol version will compare greater
than any SSL or TLS protocol version. The protocol version may be
G_TLS_PROTOCOL_VERSION_UNKNOWN if the TLS backend supports a newer
protocol version that GLib does not yet know about. This means that
it's possible for an unknown DTLS protocol version to compare less
than the TLS protocol versions.
|
No protocol version or unknown protocol version |
||
|
SSL 3.0, which is insecure and should not be used |
||
|
TLS 1.0, which is insecure and should not be used |
||
|
TLS 1.1, which is insecure and should not be used |
||
|
TLS 1.2, defined by RFC 5246 |
||
|
TLS 1.3, defined by RFC 8446 |
||
|
DTLS 1.0, which is insecure and should not be used |
||
|
DTLS 1.2, defined by RFC 6347 |
Since: 2.70