Windows Server 2022 uses version number 10.0.20348, which is less than 10.0.22000.
Therefore, instead of checking for build numbers >= 22000 (which would exclude Server 2022),
we must check for build numbers >= 20348 to correctly include both Windows Server 2022
and Windows 11.
This is safe because TLSv1.3 was first supported in:
- Windows 11 (starting with build 22000)
- Windows Server 2022 (starting with build 20348)
Earlier versions did not support TLSv1.3:
- Windows 10 (up to build 19044)
- Windows Server 2019 (latest build 17763)
Fixes slow SSL handshakes in network-restricted environments. On Windows,
the verification process uses the CertGetCertificateChain API, which
may attempt to refresh the CA list or fetch CRLs/OCSP data from the
network. This can trigger slow network lookups when no CA or CRL is
explicitly specified.
This patch disables these unnecessary network calls by using flags
like CERT_CHAIN_CACHE_ONLY_URL_RETRIEVAL to prevent external requests
during certificate chain validation. Additionally, it applies
Microsoft-recommended optimizations to speed up certificate handling
and avoid delays in SSL handshakes.
Also, unless explicitly requested(via ca_cert or crl_file or similar),
do not bother to verify name, CA or CRL for local connections. It saves
time. The failures in verification were previously discarded anyway.
- moved fingerprint verification to ma_tls.c
- don't verify cert again if fingerprint check
succeeded.
- Disable self signed check in fingerprint tests
(Schannel only).
Since the MARIADB_TLS_VERIFY_TRUST flag might be cleared in my_auth,
we store the original result of peer certificate verification in
mysql->extension->tls_validation.
This value can be obtained via mariadb_get_infov API function
using option MARIADB_TLS_VERIFY_STATUS.
Use SCH_CREDENTIAL structure, to support TLSv1.3
Allow TLSv1.3 starting with Windows 11 / Server 2022, which are
first Windows releases to officially support latest TLS version
There is no real renegotiation in TLSv1.3 protocol, so it is
some internal schannel thing, that makes DecryptMessage() to return
SEC_I_RENEGOTIATE, to replay a handshake step.
This pops up when TLSv1.3 is enabled.
The bug happens only when connecting with SSL with client certificates.
Apparently if client certificates are used in TLS handshake,
private keys for cert should be loaded into named persistent
container.This is because AcquireCredentialsHandle is done partically
out-of-process in lsass.exe, and lsass wants to read private keys from disk
See discussion in https://github.com/dotnet/runtime/issues/23749
Schannel has legacy behavior for ephemeral keys, not involving lsass,
and this is why it worked for us so far, however there are limitations.
It appears to only use rsa_sha1 for signature verification, and newer
OpenSSL no longer allows SHA1 for it, and this ends up in
"algorithm mismatch" message from schannel.
The above is just my understanding of how it works, because there is no
real documentation, the conclusion is based on discussion in
https://github.com/dotnet/runtime/issues/23749
The fix:
So storing the key in persistent named container evidently fixes it,
and this is what is done in this patch. Care is takes to destroy
key container after key is no longer needed, to
avoid filling %AppData%\Roaming\Microsoft\Crypto\RSA with tiny encrypted
key files. Thus the "persistency window" of the key in container on disk
is only for duration of AcquireCredentialsHandle
- don't verify fingerprint twice
- pci->dwVersion (certificate version) needs to be increased by 1
- use MARIADB_TLS_VERIFY_UNKNOWN for unknown tls verification errors
Peer certificate validation:
Since version 3.4 peer certificate verification is enabled by default.
It can be disabled via `mysql_optionsv`, using option
MYSQL_OPT_SSL_VERIFY_SERVER_CERT:
my_bool verify= 0;
mysql_options(mariadb, MYSQL_OPT_SSL_VERIFY_SERVER_CERT, &verify);
Self signed certificates
If the client obtained a self signed peer certificate from MariaDB server
the verification will fail, with the following exceptions:
* If the connection between client and server is considered to be secure:, e.g.
* a unix_socket is used for client server communication
* hostname is localhost (Windows operating system), 127.0.0.1 or ::1
* a specified fingerprint matches the fingerprint of the peer certificate (see below)
* a client can verify the certificate using account password, it's possible if
* account has a password
* authentication plugin is "secure without TLS", that is, one of
mysql_native_password, ed25519 or parsec.
Fingerprint verification of the peer certificate
A fingerprint is a cryptographic hash (SHA-256, SHA-384 or SHA-512) of the peer
certificate's binary data. Even if the fingerprint matches, an expired or
revoked certificate will not be accepted.
For security reasons support for MD5 and SHA1 has been removed.
Technical details:
==================
- Peer certificate verification call was removed from ma_tls_connect, instead it
will be called directly after the handshake succeeded (my_auth.c)
- mysql->net.tls_self_signed_error was replaced by mysql->net.tls_verify_status which
contains the result of the peer certfificate verification:
The verification status can be obtained with mariadb_get_infov using new parameter
MARIADB_TLS_VERIFY_STATUS.
unsigned int tls_verify_status;
mariadb_get_infov(mysql, MARIADB_TLS_VERIFY_STATUS, &tls_verify_status);
The result is a combination of the following flags:
MARIADB_TLS_VERIFY_OK 0
MARIADB_TLS_VERIFY_TRUST 1
MARIADB_TLS_VERIFY_HOST 2
MARIADB_TLS_VERIFY_PERIOD 4
MARIADB_TLS_VERIFY_FINGERPRINT 8
MARIADB_TLS_VERIFY_REVOKED 16
MARIADB_TLS_VERIFY_UNKNOWN 32
- GnuTLS peer certificate verification callback was removed and replaced by
gnutls_verify_peers2() api function, so the peer certificate validation
will happen after handshake.
- OpenSSL implementation will no longer use SSL_verify_result to check the
validity of the peer certificate. Instead a callback function will be called
during the handshake, which collects all certificate validation errors.
- If the peer certificate is not trusted, hostname verification will be
skipped.
- Testing
Added new test tls, which implements a python based dummy server, which allows
to set different certificates and TLS options. Please note. that tests are
expected to fail, since the server doesn't support further steps like user
authentication etc. after the handshake. Prerequisite for running the tls test
is Python3.
Added a new structure MARIADB_X509_INFO, which
contains information about servers certificate.
The information can be obtained via mysql_get_infov API
function:
MARIADB_X509_INFO *info;
mariadb_get_infov(mysql, MARIADB_TLS_PEER_CERT_INFO, &info);
because the default value of every option is 0
(option and option.extension are bzero-ed to reset),
tls_verify_server_cert was renamed to tls_allow_invalid_server_cert
with the default value of 0, "do not allow".
API didn't change, it's still MYSQL_OPT_SSL_VERIFY_SERVER_CERT
Since the server certification option is used by client
only, there is no need to have this flag in server and or
client capabilities. The server itself validates client
certificate depending on the user definition.
Since TLS errors might happen not only when connecting and SSL protocol
is not longer used, errormessage for CR_SSL_CONNECTION_ERROR was replaced
by TLS/SSL error.
Added cipher suites ECDHE-RSA-AES128-SHA256 (0xC027) and
ECDHE-RSA-AES256-SHA384 (0xC028) to the cipher map which maps
cipher suite names to the corresponding algorithm ids.
Since this list is still incomplete, and additional list containing
the cipher suite ids and openssl cipher suite names was added. This
list will be used now to detect the cipher suite for the current
connection.
Implement proper verification for server certificate chain,
with refactoring of the certificate stuff.
If custom CA and CRL certs are given, load them into in-memory store, and
use CertVerifyCertificateChainPolicy() to verify the certificate chain.
There are minor errors fixed, such as
- now there is a support for private keys encoded as BEGIN/END PRIVATE KEY
in PEM, instead of only BEGIN/END RSA PRIVATE KEY
- memory leak around CryptAcquireContext() is fixed i.e when client loads
private key, it previously did never released it, not even when connection
ended.
The handling of certificates moved into schannel_certs.c from various places
Print error symbol (e.g S"EC_E_ILLEGAL_MESSAGE") in the error message
for some schannel errors, in addition to error message
Print error code for all errors coming from schannel.
Fix some whitespace.
Added support for pem files which contain certificate and private key.
In case the file will contain more than one certificate or key, the first
certificate or key found will be used.
of ssl version).
We do not need to know the version of schannel.dll. Its version is always
the same as OS version. So do not add extra file IOs to the client
library.
Client part of MDEV-14101: Add support for tls-version, via
mysql_options(mysql, MARIADB_OPT_TLS_VERSION, value)
Accepted values are "TLSv1.1", "TLSv1.2" and "TLSv1.3".
Fixed testcase openssl_1 for schannel
When calling mariadb_get_infov with option MARIADB_TLS_LIBRARY
the functioni now returns the correct version number and name
of the tls/ssl library in use.
The connection pointer mysql is now no longer part (and doesn't need to be updated) of schannel security context, since it can be obtained directly from tls container.
- Fix a breaking change where
SP_PROT_TLS1_2_CLIENT bit was set in Cred.grbitEnabledProtocols by default.
This makes any SSL connection to Windows server fai, because
all yassl-based servers, in all MariaDB versions would abort
a client that is trying to use TLS1.2
(This is covered MDEV-12190)
As a consequence, client on Windows would not connect to any
server on Windows. For compatibility reasons therefore, 1.2 should NOT
be used by clients by default, otherwise it will break applications
connectivity to both Oracle MySQL and MariaDB's yassl based servers.
This also holds after MDEV-12190 is fixed, because older servers
will be used for a while.
- Cred.dwFlag was missing SCH_CRED_NO_DEFAULT_CREDS flag,
which resulted in a popup on the build servers, asking to insert
a smartcard during client SSL handshake.
Smaller bugs in schannel :
cipher_name() was returning pointer to member of stack allocated struct
Socket IO fixes
- errno rather than WSAGetLastError() was tested on Windows in
pvio_socket_write/pvio_socket_read.
Fixed by using socker_errno and simplided function to avoid numerious #ifdef _WIN32
- simplified vio_set_blocking, it had a rather inefficient implementation
setting the same flags with ioctlsocket/fcntl over and over again.
To obtain the correct cipher suite name, we use the (undocumented) flag
SECPKG_ATTR_CIPHER_INFO, which delivers cipher suite id and IANA cipher suite name.
Added more cipher suites and mappings between IANA and OpenSSL cipher suite names
between the calls.
State can be unread buffer from DecryptMessage (SECBUFFER_EXTRA)
or decrypted data that did not fit into callers buffer
- Fix error handling - SEC_I_RENEGOTIATE is handled as error,
we're not doing it yet. Stop reading at SEC_I_CONTEXT_EXPIRED.
- Fix buffer sizes pased to SSPI ( so that large buffers can be read or written
"SELECT REPEAT('a', 20000)"
- Fix unchecked memcpy into the output buffer (size of the output buffer
was not checked, so it is a potential memory overrun)
- use CertFreeCertificateContext() to free memory allocated by QueryContextAttributes(SECPKG_ATTR_REMOTE_CERT_CONTEXT)
- consistently use "SSL connection error: " prefix for schannel errors
- remove global variables
- remove in memory certificate stores that cache all CRL and all CA
- verify certificate against ssl_ca and ssl_crl specified in
connection options (not against all CRL/CA in store)
