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.
When checking for a semi sync indication header, we need also check if
the undocumented session variable @rpl_semi_sync_slave was set.
Otherwise the timestamp of the event could contain values which match
the 2 bytes of the semi sync header.
Since the variable rpl_semi_sync_slave and it's behavior is not documented,
a new option MARIADB_RPL_SEMI_SYNC was added.
Added new option MARIADB_OPT_RPL_REGISTER_REPLICA which expects
two parameters, host and port. When this option was set, rpl_open
will send a COM_REGISTER_SLAVE command with server_id, host and
port to the connected server. This information can be retrieved
by "SHOW SLAVE STATUS" command.
Example:
rc= mysql_optionsv(mysql, MARIADB_OPT_RPL_REGISTER_REPLICA,
"myhost", 123);
When receiving a ROTATE event, the offset of filename
was not computed correctly. Similiar to the
BINLOG_CHECK_POINT event filename will also be stored
in MARIADB_RPL handle
Beside already supported asynchronous replication
the replication/binlog API now supports semi
synchronous replication:
If an event contains a semi synchronous indicator (0xEF)
behind status byte and acknowledgement flag is set,
mariadb_rpl_fetch() automatically sends an acknowledge
message to the connected primary server.
