Class TlsConnection

java.lang.Object
org.javagi.base.ProxyInstance
org.gnome.gobject.TypeInstance
org.gnome.gobject.GObject
org.gnome.gio.IOStream
org.gnome.gio.TlsConnection
All Implemented Interfaces:
AutoCloseable, Proxy, AutoCloseable
Direct Known Subclasses:
TlsClientConnection.TlsClientConnection$Impl, TlsConnection.TlsConnection$Impl, TlsServerConnection.TlsServerConnection$Impl
@Generated("org.javagi.JavaGI") public abstract class TlsConnection extends IOStream

GTlsConnection is the base TLS connection class type, which wraps a IOStream and provides TLS encryption on top of it. Its subclasses, TlsClientConnection and TlsServerConnection, implement client-side and server-side TLS, respectively.

For DTLS (Datagram TLS) support, see DtlsConnection.

Since:
2.28

  • Constructor Details

    • TlsConnection

      public TlsConnection(MemorySegment address)
      Create a TlsConnection instance for the provided memory address.
      Parameters:
      address - the memory address of the native object

    • TlsConnection

      public TlsConnection()
      Create a new TlsConnection.

  • Method Details

    • getType

      public static @Nullable Type getType()
      Get the GType of the TlsConnection class.
      Returns:
      the GType

    • getMemoryLayout

      public static MemoryLayout getMemoryLayout()
      The memory layout of the native struct.
      Returns:
      the memory layout

    • asParent

      protected TlsConnection asParent()
      Return this instance as if it were its parent type. Comparable to the Java super keyword, but ensures the parent typeclass is also used in native code.
      Overrides:
      asParent in class IOStream
      Returns:
      the instance as if it were its parent type

    • emitAcceptCertificate

      public boolean emitAcceptCertificate(TlsCertificate peerCert, Set<TlsCertificateFlags> errors)
      Used by GTlsConnection implementations to emit the GTlsConnection::accept-certificate signal.
      Parameters:
      peerCert - the peer's GTlsCertificate
      errors - the problems with peerCert
      Returns:
      true if one of the signal handlers has returned true to accept peerCert
      Since:
      2.28

    • emitAcceptCertificate

      public boolean emitAcceptCertificate(TlsCertificate peerCert, TlsCertificateFlags... errors)
      Used by GTlsConnection implementations to emit the GTlsConnection::accept-certificate signal.
      Parameters:
      peerCert - the peer's GTlsCertificate
      errors - the problems with peerCert
      Returns:
      true if one of the signal handlers has returned true to accept peerCert
      Since:
      2.28

    • getCertificate

      public @Nullable TlsCertificate getCertificate()
      Gets conn's certificate, as set by g_tls_connection_set_certificate().
      Returns:
      conn's certificate, or null
      Since:
      2.28

    • getChannelBindingData

      public boolean getChannelBindingData(TlsChannelBindingType type, @Nullable Out<byte[]> data) throws GErrorException

      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.

      Parameters:
      type - GTlsChannelBindingType type of data to fetch
      data - GByteArray is filled with the binding data, or null
      Returns:
      true on success, false otherwise
      Throws:
      GErrorException - see GError
      Since:
      2.66

    • getCiphersuiteName

      public @Nullable String getCiphersuiteName()
      Returns the name of the current TLS 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.
      Returns:
      The name of the current TLS ciphersuite, or null
      Since:
      2.70

    • getDatabase

      public @Nullable TlsDatabase getDatabase()
      Gets the certificate database that this TlsConnection uses to verify peer certificates. See g_tls_connection_set_database().
      Returns:
      the certificate database that this TlsConnection uses or null
      Since:
      2.30

    • getInteraction

      public @Nullable TlsInteraction getInteraction()
      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.
      Returns:
      The interaction object.
      Since:
      2.30

    • getNegotiatedProtocol

      public @Nullable String getNegotiatedProtocol()

      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_tls_connection_set_advertised_protocols().

      Returns:
      the negotiated protocol, or null
      Since:
      2.60

    • getPeerCertificate

      public @Nullable TlsCertificate getPeerCertificate()
      Gets conn's peer's certificate after the handshake has completed or failed. (It is not set during the emission of GTlsConnection::accept-certificate.)
      Returns:
      conn's peer's certificate, or null
      Since:
      2.28

    • getPeerCertificateErrors

      public Set<TlsCertificateFlags> getPeerCertificateErrors()

      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 GTlsConnection::accept-certificate.)

      See GTlsConnection:peer-certificate-errors for more information.

      Returns:
      conn's peer's certificate errors
      Since:
      2.28

    • getProtocolVersion

      public TlsProtocolVersion getProtocolVersion()
      Returns the current TLS protocol version, which may be 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 recognized GTlsProtocolVersion.
      Returns:
      The current TLS protocol version
      Since:
      2.70

    • getRehandshakeMode

      @Deprecated public TlsRehandshakeMode getRehandshakeMode()
      Deprecated.
      Changing the rehandshake mode is no longer required for compatibility. Also, rehandshaking has been removed from the TLS protocol in TLS 1.3.
      Gets this TlsConnection rehandshaking mode. See g_tls_connection_set_rehandshake_mode() for details.
      Returns:
      TlsRehandshakeMode.SAFELY
      Since:
      2.28

    • getRequireCloseNotify

      public boolean getRequireCloseNotify()
      Tests whether or not this TlsConnection expects a proper TLS close notification when the connection is closed. See g_tls_connection_set_require_close_notify() for details.
      Returns:
      true if this TlsConnection requires a proper TLS close notification.
      Since:
      2.28

    • getUseSystemCertdb

      @Deprecated public boolean getUseSystemCertdb()
      Deprecated.
      Use g_tls_connection_get_database() instead
      Gets whether this TlsConnection uses the system certificate database to verify peer certificates. See g_tls_connection_set_use_system_certdb().
      Returns:
      whether this TlsConnection uses the system certificate database

    • handshake

      public boolean handshake(@Nullable Cancellable cancellable) throws GErrorException

      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), GTlsConnection will handle this for you automatically when you try to send or receive data on the connection. You can call g_tls_connection_handshake() manually if you want to know whether the initial handshake succeeded or failed (as opposed to just immediately trying to use this TlsConnection 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_tls_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.

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

      GTlsConnection::accept_certificate may be emitted during the handshake.

      Parameters:
      cancellable - a GCancellable, or null
      Returns:
      success or failure
      Throws:
      GErrorException - see GError
      Since:
      2.28

    • handshakeAsync

      public void handshakeAsync(int ioPriority, @Nullable Cancellable cancellable, @Nullable AsyncReadyCallback callback)
      Asynchronously performs a TLS handshake on conn. See g_tls_connection_handshake() for more information.
      Parameters:
      ioPriority - the I/O priority of the request
      cancellable - a GCancellable, or null
      callback - callback to call when the handshake is complete
      Since:
      2.28

    • handshakeFinish

      public boolean handshakeFinish(AsyncResult result) throws GErrorException
      Finish an asynchronous TLS handshake operation. See g_tls_connection_handshake() for more information.
      Parameters:
      result - a GAsyncResult.
      Returns:
      true on success, false on failure, in which case error will be set.
      Throws:
      GErrorException - see GError
      Since:
      2.28

    • setAdvertisedProtocols

      public void setAdvertisedProtocols(@Nullable String @Nullable [] 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_tls_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.

      Parameters:
      protocols - a null-terminated array of ALPN protocol names (eg, "http/1.1", "h2"), or null
      Since:
      2.60

    • setCertificate

      public void setCertificate(TlsCertificate certificate)

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

      For a GTlsClientConnection, this is optional. If a handshake fails with 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 call g_tls_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_tls_client_connection_get_accepted_cas() will return non-null.)

      Parameters:
      certificate - the certificate to use for this TlsConnection
      Since:
      2.28

    • setDatabase

      public void setDatabase(@Nullable TlsDatabase 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 TlsCertificateFlags.UNKNOWN_CA error (meaning GTlsConnection::accept-certificate will always be emitted on client-side connections, unless that bit is not set in GTlsClientConnection:validation-flags).

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

      Parameters:
      database - a GTlsDatabase
      Since:
      2.30

    • setInteraction

      public void setInteraction(@Nullable TlsInteraction 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.

      Parameters:
      interaction - an interaction object, or null
      Since:
      2.30

    • setRehandshakeMode

      @Deprecated public void setRehandshakeMode(TlsRehandshakeMode mode)
      Deprecated.
      Changing the rehandshake mode is no longer required for compatibility. Also, rehandshaking has been removed from the TLS protocol in TLS 1.3.
      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.
      Parameters:
      mode - the rehandshaking mode
      Since:
      2.28

    • setRequireCloseNotify

      public void setRequireCloseNotify(boolean requireCloseNotify)

      Sets whether or not this TlsConnection expects a proper TLS close notification before the connection is closed. If this is true (the default), then this TlsConnection will expect to receive a TLS close notification from its peer before the connection is closed, and will return a 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 g_tls_connection_set_require_close_notify() to tell this TlsConnection to allow an "unannounced" connection close, in which case the close will show up as a 0-length read, as in a non-TLS GSocketConnection, 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_io_stream_close() 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 GTlsConnection:base-io-stream rather than closing this TlsConnection itself, but note that this may only be done when no other operations are pending on this TlsConnection or the base I/O stream.

      Parameters:
      requireCloseNotify - whether or not to require close notification
      Since:
      2.28

    • setUseSystemCertdb

      @Deprecated public void setUseSystemCertdb(boolean useSystemCertdb)
      Deprecated.
      Use g_tls_connection_set_database() instead
      Sets whether this TlsConnection 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 TlsCertificateFlags.UNKNOWN_CA error (meaning GTlsConnection::accept-certificate will always be emitted on client-side connections, unless that bit is not set in GTlsClientConnection:validation-flags).
      Parameters:
      useSystemCertdb - whether to use the system certificate database

    • acceptCertificate

      protected boolean acceptCertificate(TlsCertificate peerCert, Set<TlsCertificateFlags> errors)
      Check whether to accept a certificate.

    • getBindingData

      protected boolean getBindingData(TlsChannelBindingType type, @Nullable byte @Nullable [] data) throws GErrorException
      Retrieve TLS channel binding data (Since: 2.66)
      Throws:
      GErrorException - see GError

    • onAcceptCertificate

      public SignalConnection<TlsConnection.AcceptCertificateCallback> onAcceptCertificate(TlsConnection.AcceptCertificateCallback handler)

      Emitted during the TLS handshake after the peer certificate has been received. You can examine peerCert's certification path by calling g_tls_certificate_get_issuer() 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 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 with 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 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, peerCert 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 a 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 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.

      Parameters:
      handler - the signal handler
      Returns:
      a signal handler ID to keep track of the signal connection
      Since:
      2.28
      See Also: