| qdtls.cpp |
!
\class QDtlsClientVerifier
\brief This class implements server-side DTLS cookie generation and verification.
\since 5.12
\ingroup network
\ingroup ssl
\inmodule QtNetwork
The QDtlsClientVerifier class implements server-side DTLS cookie generation
and verification. Datagram security protocols are highly susceptible to a
variety of Denial-of-Service attacks. According to \l {RFC 6347, section 4.2.1},
these are two of the more common types of attack:
\list
\li An attacker transmits a series of handshake initiation requests, causing
a server to allocate excessive resources and potentially perform expensive
cryptographic operations.
\li An attacker transmits a series of handshake initiation requests with
a forged source of the victim, making the server act as an amplifier.
Normally, the server would reply to the victim machine with a Certificate message,
which can be quite large, thus flooding the victim machine with datagrams.
\endlist
As a countermeasure to these attacks, \l {RFC 6347, section 4.2.1}
proposes a stateless cookie technique that a server may deploy:
\list
\li In response to the initial ClientHello message, the server sends a HelloVerifyRequest,
which contains a cookie. This cookie is a cryptographic hash and is generated using the
client's address, port number, and the server's secret (which is a cryptographically strong
pseudo-random sequence of bytes).
\li A reachable DTLS client is expected to reply with a new ClientHello message
containing this cookie.
\li When the server receives the ClientHello message with a cookie, it
generates a new cookie as described above. This new cookie is compared to the
one found in the ClientHello message.
\li In the cookies are equal, the client is considered to be real, and the
server can continue with a TLS handshake procedure.
\endlist
\note A DTLS server is not required to use DTLS cookies.
QDtlsClientVerifier is designed to work in pair with QUdpSocket, as shown in
the following code-excerpt:
\snippet code/src_network_ssl_qdtlscookie.cpp 0
QDtlsClientVerifier does not impose any restrictions on how the application uses
QUdpSocket. For example, it is possible to have a server with a single QUdpSocket
in state QAbstractSocket::BoundState, handling multiple DTLS clients
simultaneously:
\list
\li Testing if new clients are real DTLS-capable clients.
\li Completing TLS handshakes with the verified clients (see QDtls).
\li Decrypting datagrams coming from the connected clients (see QDtls).
\li Sending encrypted datagrams to the connected clients (see QDtls).
\endlist
This implies that QDtlsClientVerifier does not read directly from a socket,
instead it expects the application to read an incoming datagram, extract the
sender's address, and port, and then pass this data to verifyClient().
To send a HelloVerifyRequest message, verifyClient() can write to the QUdpSocket.
\note QDtlsClientVerifier does not take ownership of the QUdpSocket object.
By default QDtlsClientVerifier obtains its secret from a cryptographically
strong pseudorandom number generator.
\note The default secret is shared by all objects of the classes QDtlsClientVerifier
and QDtls. Since this can impose security risks, RFC 6347 recommends to change
the server's secret frequently. Please see \l {RFC 6347, section 4.2.1}
for hints about possible server implementations. Cookie generator parameters
can be set using the class QDtlsClientVerifier::GeneratorParameters and
setCookieGeneratorParameters():
\snippet code/src_network_ssl_qdtlscookie.cpp 1
The \l{secureudpserver}{DTLS server} example illustrates how to use
QDtlsClientVerifier in a server application.
\sa QUdpSocket, QAbstractSocket::BoundState, QDtls, verifyClient(),
GeneratorParameters, setCookieGeneratorParameters(), cookieGeneratorParameters(),
QDtls::setCookieGeneratorParameters(),
QDtls::cookieGeneratorParameters(),
QCryptographicHash::Algorithm,
QDtlsError, dtlsError(), dtlsErrorString()
|
38556 |
- |
| qdtls.h |
|
4140 |
- |
| qdtls_p.h |
|
1046 |
- |
| qocsp_p.h |
|
1255 |
- |
| qocspresponse.cpp |
!
\class QOcspResponse
\brief This class represents Online Certificate Status Protocol response.
\since 5.13
\ingroup network
\ingroup ssl
\inmodule QtNetwork
The QOcspResponse class represents the revocation status of a server's certificate,
received by the client-side socket during the TLS handshake. QSslSocket must be
configured with OCSP stapling enabled.
\sa QSslSocket, QSslSocket::ocspResponses(), certificateStatus(),
revocationReason(), responder(), subject(), QOcspCertificateStatus, QOcspRevocationReason,
QSslConfiguration::setOcspStaplingEnabled(), QSslConfiguration::ocspStaplingEnabled(),
QSslConfiguration::peerCertificate()
|
5439 |
- |
| qocspresponse.h |
|
2174 |
- |
| qocspresponse_p.h |
|
1329 |
- |
| qpassworddigestor.cpp |
!
\namespace QPasswordDigestor
\inmodule QtNetwork
\brief The QPasswordDigestor namespace contains functions which you can use
to generate hashes or keys.
|
8508 |
- |
| qpassworddigestor.h |
|
1016 |
- |
| qssl.cpp |
! \namespace QSsl
\brief The QSsl namespace declares enums common to all SSL classes in Qt Network.
\since 4.3
\ingroup network
\ingroup ssl
\inmodule QtNetwork
|
8833 |
- |
| qssl.h |
|
3969 |
- |
| qssl_p.h |
|
822 |
- |
| qsslcertificate.cpp |
!
\class QSslCertificate
\brief The QSslCertificate class provides a convenient API for an X509 certificate.
\since 4.3
\reentrant
\ingroup network
\ingroup ssl
\ingroup shared
\inmodule QtNetwork
QSslCertificate stores an X509 certificate, and is commonly used
to verify the identity and store information about the local host,
a remotely connected peer, or a trusted third party Certificate
Authority.
There are many ways to construct a QSslCertificate. The most
common way is to call QSslSocket::peerCertificate(), which returns
a QSslCertificate object, or QSslSocket::peerCertificateChain(),
which returns a list of them. You can also load certificates from
a DER (binary) or PEM (Base64) encoded bundle, typically stored as
one or more local files, or in a Qt Resource.
You can call isNull() to check if your certificate is null. By default,
QSslCertificate constructs a null certificate. A null certificate is
invalid, but an invalid certificate is not necessarily null. If you want
to reset all contents in a certificate, call clear().
After loading a certificate, you can find information about the
certificate, its subject, and its issuer, by calling one of the
many accessor functions, including version(), serialNumber(),
issuerInfo() and subjectInfo(). You can call effectiveDate() and
expiryDate() to check when the certificate starts being
effective and when it expires.
The publicKey() function returns the certificate
subject's public key as a QSslKey. You can call issuerInfo() or
subjectInfo() to get detailed information about the certificate
issuer and its subject.
Internally, QSslCertificate is stored as an X509 structure. You
can access this handle by calling handle(), but the results are
likely to not be portable.
\sa QSslSocket, QSslKey, QSslCipher, QSslError
|
34677 |
- |
| qsslcertificate.h |
|
4725 |
- |
| qsslcertificate_p.h |
|
1167 |
- |
| qsslcertificateextension.cpp |
!
\class QSslCertificateExtension
\brief The QSslCertificateExtension class provides an API for accessing the
extensions of an X509 certificate.
\since 5.0
\reentrant
\ingroup network
\ingroup ssl
\ingroup shared
\inmodule QtNetwork
QSslCertificateExtension provides access to an extension stored in
an X509 certificate. The information available depends on the type
of extension being accessed.
All X509 certificate extensions have the following properties:
\table
\header
\li Property
\li Description
\row
\li name
\li The human readable name of the extension, eg. 'basicConstraints'.
\row
\li criticality
\li This is a boolean value indicating if the extension is critical
to correctly interpreting the certificate.
\row
\li oid
\li The ASN.1 object identifier that specifies which extension this
is.
\row
\li supported
\li If this is true the structure of the extension's value will not
change between Qt versions.
\row
\li value
\li A QVariant with a structure dependent on the type of extension.
\endtable
Whilst this class provides access to any type of extension, only
some are guaranteed to be returned in a format that will remain
unchanged between releases. The isSupported() method returns \c true
for extensions where this is the case.
The extensions currently supported, and the structure of the value
returned are as follows:
\table
\header
\li Name
\li OID
\li Details
\row
\li basicConstraints
\li 2.5.29.19
\li Returned as a QVariantMap. The key 'ca' contains a boolean value,
the optional key 'pathLenConstraint' contains an integer.
\row
\li authorityInfoAccess
\li 1.3.6.1.5.5.7.1.1
\li Returned as a QVariantMap. There is a key for each access method,
with the value being a URI.
\row
\li subjectKeyIdentifier
\li 2.5.29.14
\li Returned as a QVariant containing a QString. The string is the key
identifier.
\row
\li authorityKeyIdentifier
\li 2.5.29.35
\li Returned as a QVariantMap. The optional key 'keyid' contains the key
identifier as a hex string stored in a QByteArray. The optional key
'serial' contains the authority key serial number as a qlonglong.
Currently there is no support for the general names field of this
extension.
\endtable
In addition to the supported extensions above, many other common extensions
will be returned in a reasonably structured way. Extensions that the SSL
backend has no support for at all will be returned as a QByteArray.
Further information about the types of extensions certificates can
contain can be found in RFC 5280.
\sa QSslCertificate::extensions()
|
5168 |
- |
| qsslcertificateextension.h |
|
1316 |
- |
| qsslcertificateextension_p.h |
|
971 |
- |
| qsslcipher.cpp |
!
\class QSslCipher
\brief The QSslCipher class represents an SSL cryptographic cipher.
\since 4.3
\reentrant
\ingroup network
\ingroup ssl
\ingroup shared
\inmodule QtNetwork
QSslCipher stores information about one cryptographic cipher. It
is most commonly used with QSslSocket, either for configuring
which ciphers the socket can use, or for displaying the socket's
ciphers to the user.
\sa QSslSocket, QSslKey
|
5251 |
- |
| qsslcipher.h |
|
1666 |
- |
| qsslcipher_p.h |
|
1062 |
- |
| qsslconfiguration.cpp |
!
\class QSslConfiguration
\brief The QSslConfiguration class holds the configuration and state of an SSL connection.
\since 4.4
\reentrant
\inmodule QtNetwork
\ingroup network
\ingroup ssl
\ingroup shared
QSslConfiguration is used by Qt networking classes to relay
information about an open SSL connection and to allow the
application to control certain features of that connection.
The settings that QSslConfiguration currently supports are:
\list
\li The SSL/TLS protocol to be used
\li The certificate to be presented to the peer during connection
and its associated private key
\li The ciphers allowed to be used for encrypting the connection
\li The list of Certificate Authorities certificates that are
used to validate the peer's certificate
\endlist
These settings are applied only during the connection
handshake. Setting them after the connection has been established
has no effect.
The state that QSslConfiguration supports are:
\list
\li The certificate the peer presented during handshake, along
with the chain leading to a CA certificate
\li The cipher used to encrypt this session
\endlist
The state can only be obtained once the SSL connection starts, but
not necessarily before it's done. Some settings may change during
the course of the SSL connection without need to restart it (for
instance, the cipher can be changed over time).
State in QSslConfiguration objects cannot be changed.
QSslConfiguration can be used with QSslSocket and the Network
Access API.
Note that changing settings in QSslConfiguration is not enough to
change the settings in the related SSL connection. You must call
setSslConfiguration on a modified QSslConfiguration object to
achieve that. The following example illustrates how to change the
protocol to TLSv1_2 in a QSslSocket object:
\snippet code/src_network_ssl_qsslconfiguration.cpp 0
\sa QSsl::SslProtocol, QSslCertificate, QSslCipher, QSslKey,
QSslSocket, QNetworkAccessManager,
QSslSocket::sslConfiguration(), QSslSocket::setSslConfiguration()
|
48667 |
- |
| qsslconfiguration.h |
|
6725 |
- |
| qsslconfiguration_p.h |
|
4614 |
- |
| qssldiffiehellmanparameters.cpp |
!
\class QSslDiffieHellmanParameters
\brief The QSslDiffieHellmanParameters class provides an interface for Diffie-Hellman parameters for servers.
\since 5.8
\reentrant
\ingroup network
\ingroup ssl
\ingroup shared
\inmodule QtNetwork
QSslDiffieHellmanParameters provides an interface for setting Diffie-Hellman parameters to servers based on QSslSocket.
\sa QSslSocket, QSslCipher, QSslConfiguration
|
9793 |
- |
| qssldiffiehellmanparameters.h |
|
2851 |
- |
| qssldiffiehellmanparameters_p.h |
|
1026 |
- |
| qsslellipticcurve.cpp |
!
\class QSslEllipticCurve
\since 5.5
\brief Represents an elliptic curve for use by elliptic-curve cipher algorithms.
\reentrant
\ingroup network
\ingroup ssl
\inmodule QtNetwork
The class QSslEllipticCurve represents an elliptic curve for use by
elliptic-curve cipher algorithms.
Elliptic curves can be constructed from a "short name" (SN) (fromShortName()),
and by a call to QSslConfiguration::supportedEllipticCurves().
QSslEllipticCurve instances can be compared for equality and can be used as keys
in QHash and QSet. They cannot be used as key in a QMap.
\note This class is currently only supported in OpenSSL.
|
4940 |
- |
| qsslellipticcurve.h |
|
1949 |
- |
| qsslerror.cpp |
!
\class QSslError
\brief The QSslError class provides an SSL error.
\since 4.3
\reentrant
\ingroup network
\ingroup ssl
\ingroup shared
\inmodule QtNetwork
QSslError provides a simple API for managing errors during QSslSocket's
SSL handshake.
\sa QSslSocket, QSslCertificate, QSslCipher
|
10340 |
- |
| qsslerror.h |
|
3516 |
- |
| qsslkey.h |
|
2083 |
- |
| qsslkey_p.cpp |
!
\class QSslKey
\brief The QSslKey class provides an interface for private and public keys.
\since 4.3
\reentrant
\ingroup network
\ingroup ssl
\ingroup shared
\inmodule QtNetwork
QSslKey provides a simple API for managing keys.
\sa QSslSocket, QSslCertificate, QSslCipher
|
9483 |
- |
| qsslkey_p.h |
|
1232 |
- |
| qsslkeyingmaterial.cpp |
!
\class QSslKeyingMaterial
\since 6.12
\preliminary
\brief Describes exported keying material derived from a TLS session.
\reentrant
\ingroup network
\ingroup ssl
\inmodule QtNetwork
\compares equality
QSslKeyingMaterial represents a request for keying material derived
from an established TLS connection using the TLS exporter mechanism.
The exporter mechanism is defined in RFC 5705 for TLS 1.2 and earlier
and in RFC 8446 for TLS 1.3. It allows applications to derive
cryptographically separate keying material from the TLS session
without exposing the session's traffic keys.
Each QSslKeyingMaterial object specifies:
\list
\li an exporter label identifying the purpose of the derived
keying material
\li an optional context value binding the keying material to
application-specific data
\li the desired size of the exported keying material
\endlist
The actual keying material is derived by the TLS backend after a
successful handshake and can be read with value().
QSslKeyingMaterial objects are typically configured via
QSslConfiguration::setKeyingMaterial() before initiating a TLS
connection.
Example: Deterministic export on client and server
\code
// Both client and server configure the same label and optional context
QSslKeyingMaterial keying("session-label", 32, "app-specific-context");
// After the TLS handshake completes get data from QSslConfiguration.
QByteArray derived = sslConfiguration().takeKeyingMaterial(keying)->value();
// Both client and server will obtain the same 'derived' bytes
// even though they each performed the derivation independently.
use(derived);
\endcode
\section1 Security Considerations
Exported keying material is a secret. QByteArray is a copy-on-write
container, so every QSslKeyingMaterial object holding a value shares one
buffer, and the secret remains in memory for as long as any of those
objects lives. An application that needs to guarantee it holds the only
remaining reference must release the Qt-internal ones explicitly.
After a successful handshake the value lives in exactly one place inside
Qt: the QSslKeyingMaterial entry in the socket's internal
QSslConfiguration. Each QSslConfiguration returned by
QSslSocket::sslConfiguration() is an independent copy of that
configuration, sharing the value's buffer with it.
Both QSslConfiguration::takeKeyingMaterial() overloads hand the values over
instead of sharing them: what they return holds the only reference to the
value, and the entries they leave behind in the configuration they were
called on are valueless \l{clone()}{clones}. Copy the value out of the
returned object with \l value() and let the object itself go out of scope,
then write the configuration back to the socket: that overwrites the
socket's entry with the valueless one, dropping the last reference Qt
holds.
\code
QSslConfiguration config = socket->sslConfiguration();
// Copy the value out of the temporary that owns it, and let it die:
QByteArray secret = config.takeKeyingMaterial(request)->value();
// Overwrite the socket's copy with the entry left behind, which has no value:
socket->setSslConfiguration(config);
\endcode
The following copies are outside the socket's control and must be dealt
with separately:
\list
\li Any other QSslConfiguration copy the application still holds,
including one stored in a QNetworkRequest or installed with
QSslConfiguration::setDefaultConfiguration(). Taking the value
from one copy does not affect the others.
\li A configuration that was never written back to the socket. Taking
the values out of a QSslConfiguration only strips that copy of the
configuration; the socket keeps its own until it is given the
valueless entries.
\li Any QSslKeyingMaterial copy the application made itself. Use
\l clone() when a copy of a request is needed without its value.
\endlist
The socket also drops the values when it starts a new handshake, because
its entries are reset to valueless clones then, and when it is destroyed.
Neither replaces the explicit step above for a socket that stays alive.
|
10907 |
- |
| qsslkeyingmaterial.h |
|
3189 |
- |
| qsslpresharedkeyauthenticator.cpp |
!
\internal
|
7239 |
- |
| qsslpresharedkeyauthenticator.h |
|
2324 |
- |
| qsslpresharedkeyauthenticator_p.h |
|
964 |
- |
| qsslserver.cpp |
!
\class QSslServer
\ingroup network
\ingroup ssl
\inmodule QtNetwork
\since 6.4
\brief Implements an encrypted, secure TCP server over TLS.
Class to use in place of QTcpServer to implement TCP server using
Transport Layer Security (TLS).
To configure the secure handshake settings, use the applicable setter
functions on a QSslConfiguration object, and then use it as an argument
to the setSslConfiguration() function. All following incoming
connections handled will use these settings.
To start listening to incoming connections use the listen() function
inherited from QTcpServer. Other settings can be configured by using the
setter functions inherited from the QTcpServer class.
Connect to the signals of this class to respond to the incoming connection
attempts. They are the same as the signals on QSslSocket, but also
passes a pointer to the socket in question.
When responding to the pendingConnectionAvailable() signal, use the
nextPendingConnection() function to fetch the next incoming connection and
take it out of the pending connection queue. The QSslSocket is a child of
the QSslServer and will be deleted when the QSslServer is deleted. It is
still a good idea to destroy the object explicitly when you are done
with it, to avoid wasting memory.
\sa QTcpServer, QSslConfiguration, QSslSocket
|
15469 |
- |
| qsslserver.h |
|
1947 |
- |
| qsslserver_p.h |
|
2157 |
- |
| qsslsocket.cpp |
|
100097 |
- |
| qsslsocket.h |
|
7269 |
- |
| qsslsocket_p.h |
|
5551 |
- |
| qtlsbackend.cpp |
!
\class QTlsBackend
\internal (Network-private)
\brief QTlsBackend is a factory class, providing implementations
for the QSsl classes.
The purpose of QTlsBackend is to enable and simplify the addition
of new TLS backends to be used by QSslSocket and related classes.
Starting from Qt 6.1, these backends have plugin-based design (and
thus can co-exist simultaneously, unlike pre 6.1 times), although
any given run of a program can only use one of them.
Inheriting from QTlsBackend and creating an object of such
a class adds a new backend into the list of available TLS backends.
A new backend must provide a list of classes, features and protocols
it supports, and override the corresponding virtual functions that
create backend-specific implementations for these QSsl-classes.
The base abstract class - QTlsBackend - provides, where possible,
default implementations of its virtual member functions. These
default implementations can be overridden by a derived backend
class, if needed.
QTlsBackend also provides some auxiliary functions that a derived
backend class can use to interact with the internals of network-private classes.
\sa QSslSocket::availableBackends(), supportedFeatures(), supportedProtocols(), implementedClasses()
|
73072 |
- |
| qtlsbackend_p.h |
|
16469 |
- |