[MDEV-31855] validate ssl certificates using client password - Jira

Sergei Golubchik created issue - 2023-08-05 16:42

Sergei Golubchik made changes - 2023-08-05 16:46

Field	Original Value	New Value
Link		This issue blocks ~~MDEV-31856~~ [ ~~MDEV-31856~~ ]

Sergei Golubchik made changes - 2023-08-05 16:49

Link

This issue blocks ~~MDEV-31857~~ [ ~~MDEV-31857~~ ]

Sergei Golubchik made changes - 2023-08-05 16:56

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password.

*Authentication works like this*

Client side:

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation
* then append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side:

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password.

*Authentication works like this*

Client side (implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation
* then append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble

Sergei Golubchik made changes - 2023-08-05 16:57

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password.

*Authentication works like this*

Client side (implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation
* then append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password.

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation
* then append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble

Sergei Golubchik made changes - 2023-08-05 17:41

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password.

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation
* then append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password.

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation
* then append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't

Sergei Golubchik made changes - 2023-08-06 07:10

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password.

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation
* then append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation
* then append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't

Sergei Golubchik made changes - 2023-08-06 09:45

Link

This issue blocks ~~MDEV-31857~~ [ ~~MDEV-31857~~ ]

Sergei Golubchik made changes - 2023-08-06 09:46

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation
* then append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't

Sergei Golubchik made changes - 2023-08-06 09:58

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't

Sergei Golubchik made changes - 2023-08-07 11:21

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"

Julien Fritsch made changes - 2023-08-08 16:48

Priority

Major [ 3 ]

Critical [ 2 ]

Daniel Lenski (Inactive) added a comment - 2023-08-10 16:35

validate ssl certificates using client password

What security properties of the client-server connection would actually be improved by doing this?

It seems to me that this will greatly complicate the MariaDB client and server code. In my opinion, it is a bad design, because it further entrenches the entangling of two logically-separate concerns:

Transport-layer: establishing an encrypted channel between the client and an authenticated server (TLS)
Application-layer authentication and authorization

Entangling these is an extremely bad design choice, that has already led to several security vulnerabilities and greatly complicates solving them in a clean and backwards-compatible way, including at least ~~CONC-648~~, CONC-654, and MDEV-31585. I wrote at greatly length about this in a comment on CONC-648.

So, I would say that it's important to step back and think about what the goal is here, in terms of improving the security properties of the system, and then think about how to achieve that in ways that reduce, rather than exacerbate, existing security vulnerabilities and design flaws.

Daniel Lenski (Inactive) added a comment - 2023-08-10 16:35 validate ssl certificates using client password What security properties of the client-server connection would actually be improved by doing this? It seems to me that this will greatly complicate the MariaDB client and server code. In my opinion, it is a bad design, because it further entrenches the entangling of two logically-separate concerns: Transport -layer: establishing an encrypted channel between the client and an authenticated server (TLS) Application -layer authentication and authorization Entangling these is an extremely bad design choice, that has already led to several security vulnerabilities and greatly complicates solving them in a clean and backwards-compatible way, including at least CONC-648 , CONC-654 , and MDEV-31585 . I wrote at greatly length about this in a comment on CONC-648 . So, I would say that it's important to step back and think about what the goal is here, in terms of improving the security properties of the system, and then think about how to achieve that in ways that reduce, rather than exacerbate, existing security vulnerabilities and design flaws.

Sergei Golubchik added a comment - 2023-08-10 17:36 - edited

The goal is to prevent active MitM of course by validating SSL certificates.

And no, the implementation (V1) of this is quite small and simple.

Sergei Golubchik added a comment - 2023-08-10 17:36 - edited The goal is to prevent active MitM of course by validating SSL certificates. And no, the implementation (V1) of this is quite small and simple.

Sergei Golubchik made changes - 2023-08-10 23:14

Assignee

Sergei Golubchik [ serg ]

Sergei Golubchik made changes - 2023-08-11 09:06

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate *failed* validation and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"

Sergei Golubchik made changes - 2023-08-11 11:48

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{--ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"

Sergei Golubchik made changes - 2023-08-11 11:48

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{--ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"

Sergei Golubchik made changes - 2023-08-16 08:46

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)

{panel:title=Original specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Sergei Golubchik made changes - 2023-08-16 08:48

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)

{panel:title=Original specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Daniel Lenski (Inactive) added a comment - 2023-08-16 20:28

The goal is to prevent active MitM of course by validating SSL certificates.

The title of this JIRA is “validate ssl certificates using client password”.

How is validation of the server’s SSL certificate (that's a transport-layer concern) conceivably related to the client’s MariaDB user password (that's an application-layer concern)?

Daniel Lenski (Inactive) added a comment - 2023-08-16 20:28 The goal is to prevent active MitM of course by validating SSL certificates. The title of this JIRA is “validate ssl certificates using client password ”. How is validation of the server’s SSL certificate (that's a transport -layer concern) conceivably related to the client’s MariaDB user password (that's an application -layer concern)?

Sergei Golubchik made changes - 2023-08-18 13:30

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 08:52

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and {{--ssl-verify-server-cert}} is in force, but
** no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
** the certificate failed validation as self-signed, and
* *client authentication plugin doesn't have {{hash_password()}} method, then
** disconnect, otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 08:53

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and {{--ssl-verify-server-cert}} is in force, but
** no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
** the certificate failed validation as self-signed, and
* *client authentication plugin doesn't have {{hash_password()}} method, then
** disconnect, otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and {{--ssl-verify-server-cert}} is in force, but
** no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
** the certificate failed validation as self-signed, and
**client authentication plugin doesn't have {{hash_password()}} method, then
** disconnect, otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 08:54

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and {{--ssl-verify-server-cert}} is in force, but
** no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
** the certificate failed validation as self-signed, and
**client authentication plugin doesn't have {{hash_password()}} method, then
** disconnect, otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and {{--ssl-verify-server-cert}} is in force, but
** no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
** the certificate failed validation as self-signed, and
**client authentication plugin doesn't have {{hash_password()}} method, then
*** disconnect
**otherwise
*** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 08:56

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* if SSL is used, and {{--ssl-verify-server-cert}} is in force, but
** no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
** the certificate failed validation as self-signed, and
**client authentication plugin doesn't have {{hash_password()}} method, then
*** disconnect
**otherwise
*** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
{{code}}
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
   no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
   the certificate failed validation as self-signed, and
   client authentication plugin doesn't have {{hash_password()}} method
   then
     disconnect
   otherwise
     continue (let's call it _late certificate validation_ mode)
{{\code}}

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 09:03

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
{{code}}
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
   no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
   the certificate failed validation as self-signed, and
   client authentication plugin doesn't have {{hash_password()}} method
   then
     disconnect
   otherwise
     continue (let's call it _late certificate validation_ mode)
{{\code}}

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
{code}
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
   no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
   the certificate failed validation as self-signed, and
   client authentication plugin doesn't have {{hash_password()}} method
   then
     disconnect
   otherwise
     continue (let's call it _late certificate validation_ mode)
{code}

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 09:04

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
{code}
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
   no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
   the certificate failed validation as self-signed, and
   client authentication plugin doesn't have {{hash_password()}} method
   then
     disconnect
   otherwise
     continue (let's call it _late certificate validation_ mode)
{code}

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
{preformated}
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
   no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
   the certificate failed validation as self-signed, and
   client authentication plugin doesn't have {{hash_password()}} method
   then
     disconnect
   otherwise
     continue (let's call it _late certificate validation_ mode)
{preformated}

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 09:05

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
{preformated}
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
   no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
   the certificate failed validation as self-signed, and
   client authentication plugin doesn't have {{hash_password()}} method
   then
     disconnect
   otherwise
     continue (let's call it _late certificate validation_ mode)
{preformated}

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
{noformat}
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
   no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
   the certificate failed validation as self-signed, and
   client authentication plugin doesn't have {{hash_password()}} method
   then
     disconnect
   otherwise
     continue (let's call it _late certificate validation_ mode)
{noformat}

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 09:08

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
{noformat}
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
   no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
   the certificate failed validation as self-signed, and
   client authentication plugin doesn't have {{hash_password()}} method
   then
     disconnect
   otherwise
     continue (let's call it _late certificate validation_ mode)
{noformat}

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
** no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
** the certificate failed validation as self-signed, and
** client authentication plugin doesn't have {{hash_password()}} method
* then
** disconnect
* otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 09:09

Description

*This needs a change in the client auth plugin API*

* client authentication plugins get a method {{hash_password()}}, the same as in the server plugin

*Authentication works like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
** no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
** the certificate failed validation as self-signed, and
** client authentication plugin doesn't have {{hash_password()}} method
* then
** disconnect
* otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method
* then
* disconnect
* otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 09:10

Description

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method
* then
* disconnect
* otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method
* then
** disconnect
* otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 09:50

Description

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method
* then
** disconnect
* otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method
* then
** disconnect
* otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison: (old idea for the same problem)|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Michael Widenius made changes - 2023-08-19 09:51

Description

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method
* then
** disconnect
* otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this approach allows the client to validate the server itself, not just the wire

{panel:title=V1 specs for comparison: (old idea for the same problem)|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method
* then
** disconnect
* otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs (previous attempt to solve the issue), this new approach allows the client to validate the server itself, not just the wire.

{panel:title=V1 specs for comparison: (old idea for the same problem)|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Sergei Golubchik made changes - 2023-08-19 18:31

Description

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method
* then
** disconnect
* otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs (previous attempt to solve the issue), this new approach allows the client to validate the server itself, not just the wire.

{panel:title=V1 specs for comparison: (old idea for the same problem)|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method
* then
** disconnect
* otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs (previous attempt to solve the issue), this new approach allows the client to validate the server itself, not just the wire.

{panel:title=V1 specs for comparison: (old idea for the same problem)|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Sergei Golubchik made changes - 2023-08-19 18:34

Description

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method
* then
** disconnect
* otherwise
** continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs (previous attempt to solve the issue), this new approach allows the client to validate the server itself, not just the wire.

{panel:title=V1 specs for comparison: (old idea for the same problem)|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, and
* the non-empty password was provided, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, and,
* the account has non-empty password, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this new approach allows the client to validate the server itself, not just the wire.

{panel:title=First version (V1) of the solution for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Sergei Golubchik made changes - 2023-08-19 18:35

Description

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, and
* the non-empty password was provided, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, and,
* the account has non-empty password, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this new approach allows the client to validate the server itself, not just the wire.

{panel:title=First version (V1) of the solution for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, and
* the non-empty password was provided, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, and
* the account has non-empty password, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this new approach allows the client to validate the server itself, not just the wire.

{panel:title=First version (V1) of the solution for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Sergei Golubchik made changes - 2023-08-19 18:37

Description

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, and
* the non-empty password was provided, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, and
* the account has non-empty password, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this new approach allows the client to validate the server itself, not just the wire.

{panel:title=First version (V1) of the solution for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} is in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, and
* the non-empty password was provided, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, and
* the account has non-empty password, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this new approach allows the client to validate the server itself, not just the wire.

{panel:title=First version (V1) of the solution for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Sergei Golubchik made changes - 2023-08-21 09:03

Description

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} is in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, and
* the non-empty password was provided, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is self-signed, and
* the account has non-empty password, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this new approach allows the client to validate the server itself, not just the wire.

{panel:title=First version (V1) of the solution for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} is in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, and
* the non-empty password was provided, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is ephemeral (after ~~MDEV-31856~~), and
* the account has non-empty password, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this new approach allows the client to validate the server itself, not just the wire.

{panel:title=First version (V1) of the solution for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

Sergei Golubchik made changes - 2023-08-21 18:22

Status

Open [ 1 ]

In Progress [ 3 ]

Sergei Golubchik made changes - 2023-08-21 18:22

Status

In Progress [ 3 ]

Stalled [ 10000 ]

Sergei Golubchik made changes - 2023-08-23 16:32

Link

This issue relates to MDEV-31994 [ MDEV-31994 ]

Sergei Golubchik made changes - 2023-08-23 16:32

Link

This issue relates to MDEV-31994 [ MDEV-31994 ]

Diego Dupin made changes - 2023-08-30 16:23

Link

This issue relates to ~~CONJ-1105~~ [ ~~CONJ-1105~~ ]

Diego Dupin made changes - 2023-08-30 16:25

Link

This issue relates to ~~CONJS-264~~ [ ~~CONJS-264~~ ]

Sergei Golubchik made changes - 2023-09-08 14:25

Assignee	Sergei Golubchik [ serg ]	Oleksandr Byelkin [ sanja ]
Status	Stalled [ 10000 ]	In Review [ 10002 ]

Sergei Golubchik added a comment - 2023-09-08 14:29 - edited

in bb-11.3-serg branch, commits:

2c293980590 MDEV-31857 enable --ssl-verify-server-cert by default in the internal client

92d1e29f9eb MDEV-31855 validate ssl certificates using client password in the internal client

dc725663522 disable SSL via named pipes in the internal client

fecaa34d58a free mysql->connector_fd correctly in the internal client

d61d5c2b2f5 change how self-signed certs are accepted by internal client

4354452378d cleanup: X509_check_host() in the internal client

a170006cce6 cleanup: ssl handling in the internal rpl client

350cb3f311f MDEV-31857 enable --ssl-verify-server-cert by default

0131af509a9 enable --ssl in the server by default

b3fe66e7299 MDEV-31856 use ephemeral ssl certificates

8d608f6811e wrong error for bare --ssl on the server side

e651ca6497a cleanup

1ccb8bc0d78 test SSL MitM attack

a8895302211 client support for --tls-fp and --tls--fplist

3d6d49641f3 MDEV-31855 validate ssl certificates using client password

88b1c98c2d8 cleanup: unify client's setting of ssl options

6f0d7df2cb4 test.cnf files should !include default_my.cnf

8b573729ba6 clarify CR_OK_HANDSHAKE_COMPLETE

Sergei Golubchik added a comment - 2023-09-08 14:29 - edited in bb-11.3-serg branch, commits: 2c293980590 MDEV-31857 enable --ssl-verify-server-cert by default in the internal client 92d1e29f9eb MDEV-31855 validate ssl certificates using client password in the internal client dc725663522 disable SSL via named pipes in the internal client fecaa34d58a free mysql->connector_fd correctly in the internal client d61d5c2b2f5 change how self-signed certs are accepted by internal client 4354452378d cleanup: X509_check_host() in the internal client a170006cce6 cleanup: ssl handling in the internal rpl client 350cb3f311f MDEV-31857 enable --ssl-verify-server-cert by default 0131af509a9 enable --ssl in the server by default b3fe66e7299 MDEV-31856 use ephemeral ssl certificates 8d608f6811e wrong error for bare --ssl on the server side e651ca6497a cleanup 1ccb8bc0d78 test SSL MitM attack a8895302211 client support for --tls-fp and --tls--fplist 3d6d49641f3 MDEV-31855 validate ssl certificates using client password 88b1c98c2d8 cleanup: unify client's setting of ssl options 6f0d7df2cb4 test.cnf files should !include default_my.cnf 8b573729ba6 clarify CR_OK_HANDSHAKE_COMPLETE

Oleksandr Byelkin added a comment - 2023-09-12 11:36

OK to push (after adding coments about format of the protocol extention (SSL info))

Oleksandr Byelkin added a comment - 2023-09-12 11:36 OK to push (after adding coments about format of the protocol extention (SSL info))

Oleksandr Byelkin made changes - 2023-09-12 11:36

Status

In Review [ 10002 ]

Stalled [ 10000 ]

Oleksandr Byelkin made changes - 2023-09-12 11:36

Assignee

Oleksandr Byelkin [ sanja ]

Sergei Golubchik [ serg ]

Sergei Golubchik made changes - 2023-09-12 19:53

Link

This issue is part of TODO-4253 [ TODO-4253 ]

Sergei Golubchik made changes - 2023-09-13 17:50

Link

This issue relates to R2DBC-90 [ R2DBC-90 ]

Daniel Lenski (Inactive) added a comment - 2023-09-15 23:58 - edited

sanja wrote:

OK to push (after adding coments about format of the protocol extention (SSL info))

Yikes.

Do you understand that serg is essentially proposing a new TLS key exchange mechanism here?

Have you solicited the help of experts in cryptographic protocol design who can evaluate the security of this mechanism?

If I were to provide a step-by-step explanation of how this mechanism could be attacked and the client's password stolen undetectably, would you change you mind about "okay to push"?

In a comment on ~~MDEV-31856~~, serg wrote:

yes, sure. the design document is in ~~MDEV-31855~~. There's a full high-level description of the new protocol extension.
I'd appreciate if you'd try to come up with attacks against it.

Yes, I already have a detailed step-by-step attack against it.

Using this attack, it is possible for a MITM to fool the client into thinking that it has connected to a server, when it has in fact connected to the MITM, and for the MITM to obtain the client's password.

This attack is exacerbated by a (seemingly-unrelated) security flaw in MariaDB which has never been reported, to my knowledge. It is a very good illustration of why it is dangerous to mix authentication at different protocol layers, as I've been explaining over and over.

Do you want me to explain it?

Daniel Lenski (Inactive) added a comment - 2023-09-15 23:58 - edited sanja wrote: OK to push (after adding coments about format of the protocol extention (SSL info)) Yikes. Do you understand that serg is essentially proposing a new TLS key exchange mechanism here? Have you solicited the help of experts in cryptographic protocol design who can evaluate the security of this mechanism? If I were to provide a step-by-step explanation of how this mechanism could be attacked and the client's password stolen undetectably , would you change you mind about "okay to push"? In a comment on MDEV-31856 , serg wrote: yes, sure. the design document is in MDEV-31855 . There's a full high-level description of the new protocol extension. I'd appreciate if you'd try to come up with attacks against it. Yes, I already have a detailed step-by-step attack against it. Using this attack, it is possible for a MITM to fool the client into thinking that it has connected to a server, when it has in fact connected to the MITM, and for the MITM to obtain the client's password . This attack is exacerbated by a (seemingly-unrelated) security flaw in MariaDB which has never been reported, to my knowledge. It is a very good illustration of why it is dangerous to mix authentication at different protocol layers, as I've been explaining over and over. Do you want me to explain it?

Sergei Golubchik added a comment - 2023-09-16 09:40

of course, if you were to provide a step-by-step explanation of how this mechanism could be attacked, we won't push this feature in this form.

Sergei Golubchik added a comment - 2023-09-16 09:40 of course, if you were to provide a step-by-step explanation of how this mechanism could be attacked, we won't push this feature in this form.

Sergei Golubchik made changes - 2023-09-18 12:49

Description

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} is in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, and
* the non-empty password was provided, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is ephemeral (after ~~MDEV-31856~~), and
* the account has non-empty password, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)
* Unlike the V1 specs, this new approach allows the client to validate the server itself, not just the wire.

{panel:title=First version (V1) of the solution for comparison:|bgColor=#EEEEEE}
*This needs a change in the client auth plugin API*

* client authentication plugins get a property "can validate SSL certificates". It's TRUE for ed25519 and mysql_native_password, and
* {{MYSQL_PLUGIN_VIO_INFO}} gets a field for SSL cert fingerprint or even {{SSL_CTX}}

alternatively
* {{MYSQL_PLUGIN_VIO}} gets {{ssl_fingerprint()}} callback — and calling it serves as a flag, a separate flag isn't needed

*Authentication works like this*

Client side (last step is implemented inside ed25519 and mysql_native_password client plugins):

* if SSL is used and
* {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} are in force, and
* the certificate failed validation because it's self-signed, and
* the client plugin supports SSL certificate validation, then
* append (concatenate) SSL certificate fingerprint to the scramble (as sent by the server) and use that in the auth protocol

Server side (implemented inside ed25519 and mysql_native_password server plugins):

* concatenate the scramble and the SSL certificate fingerprint and use that in the auth
* if failed, repeat with the original scramble, or
* client's reply can indicate whether it used ssl fingerprint. e.g with an extra byte being "1" (protocol version?)

*Notes*
* plugin versions and the API version have to be incremented
* "concatenate" might be replaced by some other "mixing", but it should be irreversible, SHA2 will do, XOR won't
* the server has no way of distinguishing between "incorrect password" and "MitM SSL attack" — either we shoul extend the above to be able to distinguish or have a new error message "password incorrect or MitM SSL attack"
{panel}

*This needs a change in the client auth plugin API*

* client authentication plugins to get a new method {{hash_password()}}, the same as in the server plugin

*The new authentication will work like this*

Client side, when sending client reply packet:
* If SSL is used, and {{--ssl-verify-server-cert}} is in force, but
* no {{\-\-ssl-ca}} or {{--ssl-fingerprint}} is in force, and
* the certificate failed validation as self-signed, and
* client authentication plugin doesn't have {{hash_password()}} method, and
* the non-empty password was provided, then
* disconnect, otherwise
* continue (let's call it _late certificate validation_ mode)

Server side, when sending the OK packet after successful authentication:
* if SSL is used, and
* the certificate is ephemeral (after ~~MDEV-31856~~), and
* the account has non-empty password, then
* calculate SHA2(user's hashed password, scramble, certificate fingerprint), and
* put it in the OK's info field, prefixed by byte 0x01

Client side, when receiving OK packet:
* if in the _late certificate validation_ mode, then
* use {{hash_password()}} callback, calculate SHA2(user's hashed password, scramble, certificate fingerprint), compare

*Notes*
* client plugin versions and the API version have to be incremented
* the server doesn't know if the client is in the _late password validation_ mode, so it might do some unnecessary work just in case
** this could be fixed by a new capability bit, or
** just live with potential unnecessary work on connect — it is assumed that in overwhelming majority of the cases this work will be necessary (almost all setups will use this mode)

Daniel Lenski (Inactive) added a comment - 2023-09-18 23:25

I have already reported several practical TLS attacks against actual production MariaDB code which has existed for many years, e.g. ~~CONC-648~~, CONC-654, ~~CONC-656~~, MDEV-31585. I've proposed fixes for all of these; they remain mostly unfixed.

I would describe all these bugs as "pretty obvious": I didn't set out to find TLS bugs in MariaDB, but once I started looking at the relevant code for other reasons, they started to jump out at me all over the place.

I've also explained several times (e.g. comment on CONC-648 from 3 months ago how these vulnerabilities are largely a consequence of improper entanglement between different conceptually separate layers of networking protocols. This is not some very specialized knowledge: it's included in basically every guide to programming with TLS, and in many reports of previous real-world TLS vulnerabilities.

What you have proposed here, serg, is yet another new entanglement between the application-layer authentication (e.g. MariaDB native password auth) and the transport-layer security mechanism (TLS), as I mentioned in a comment right above).

of course, if you were to provide a step-by-step explanation of how this mechanism could be attacked, we won't push this feature in this form.

I am less concerned about the particular vulnerability that you are going to introduce if you merge this code, than I am with what appears to be broken or missing processes in MariaDB development.

It appears that there must be little or no review of the security implications of code changes like the one proposed here.

Daniel Lenski (Inactive) added a comment - 2023-09-18 23:25 I have already reported several practical TLS attacks against actual production MariaDB code which has existed for many years , e.g. CONC-648 , CONC-654 , CONC-656 , MDEV-31585 . I've proposed fixes for all of these; they remain mostly unfixed. I would describe all these bugs as "pretty obvious": I didn't set out to find TLS bugs in MariaDB, but once I started looking at the relevant code for other reasons, they started to jump out at me all over the place. I've also explained several times (e.g. comment on CONC-648 from 3 months ago how these vulnerabilities are largely a consequence of improper entanglement between different conceptually separate layers of networking protocols . This is not some very specialized knowledge: it's included in basically every guide to programming with TLS, and in many reports of previous real-world TLS vulnerabilities. What you have proposed here, serg , is yet another new entanglement between the application-layer authentication (e.g. MariaDB native password auth) and the transport-layer security mechanism (TLS), as I mentioned in a comment right above ). of course, if you were to provide a step-by-step explanation of how this mechanism could be attacked, we won't push this feature in this form. I am less concerned about the particular vulnerability that you are going to introduce if you merge this code, than I am with what appears to be broken or missing processes in MariaDB development. It appears that there must be little or no review of the security implications of code changes like the one proposed here.

Sergei Golubchik added a comment - 2023-09-19 07:30

Neither issue you mentioned above is a TLS attack, and 3 out of four are not even at "attack" as such.

Thank you for confirming that you're less concerned about this particular protocol extension, supposedly it means that there is no step-by-step explanation of how this mechanism could be attacked.

Sergei Golubchik added a comment - 2023-09-19 07:30 Neither issue you mentioned above is a TLS attack, and 3 out of four are not even at "attack" as such. Thank you for confirming that you're less concerned about this particular protocol extension, supposedly it means that there is no step-by-step explanation of how this mechanism could be attacked.

Sergei Golubchik made changes - 2023-09-19 13:25

Status

Stalled [ 10000 ]

In Testing [ 10301 ]

Sergei Golubchik made changes - 2023-09-19 13:26

Assignee

Sergei Golubchik [ serg ]

Alice Sherepa [ alice ]

Diego Dupin made changes - 2023-09-20 15:44

Link

This issue relates to ~~MDEV-32210~~ [ ~~MDEV-32210~~ ]

Ralf Gebhardt made changes - 2023-09-21 11:57

Labels

Preview_11.3

markus makela made changes - 2023-09-22 10:11

Link

This issue relates to ~~MXS-4774~~ [ ~~MXS-4774~~ ]

Sergei Golubchik made changes - 2023-10-18 14:01

Assignee

Alice Sherepa [ alice ]

Lena Startseva [ JIRAUSER50478 ]

Lena Startseva added a comment - 2023-10-20 12:21 - edited

serg, please, make a small changes in test main.ssl_autoverify in cases with "- - no-defaults" option - add option "--character-sets-dir" with value otherwise on some environments I get warnings in this cases:

../mariadb: Warning: Charset id '33' csname 'utf8' trying to replace existing csname 'utf8mb3'

../mariadb: Warning: Charset id '83' csname 'utf8' trying to replace existing csname 'utf8mb3'

Lena Startseva added a comment - 2023-10-20 12:21 - edited serg , please, make a small changes in test main.ssl_autoverify in cases with "- - no-defaults" option - add option "--character-sets-dir" with value otherwise on some environments I get warnings in this cases: ../mariadb: Warning: Charset id '33' csname 'utf8' trying to replace existing csname 'utf8mb3' ../mariadb: Warning: Charset id '83' csname 'utf8' trying to replace existing csname 'utf8mb3'

Sergei Golubchik added a comment - 2023-10-20 20:20

Fixed, thanks

Sergei Golubchik added a comment - 2023-10-20 20:20 Fixed, thanks

Sergei Golubchik made changes - 2023-11-19 23:36

Fix Version/s		11.4 [ 29301 ]
Fix Version/s	11.3 [ 28565 ]

Ralf Gebhardt made changes - 2023-12-12 21:25

Issue Type

Task [ 3 ]

New Feature [ 2 ]

Lena Startseva added a comment - 2024-01-23 15:35

Testing done. Ok to push

Lena Startseva added a comment - 2024-01-23 15:35 Testing done. Ok to push

Lena Startseva made changes - 2024-01-23 15:35

Assignee	Lena Startseva [ JIRAUSER50478 ]	Sergei Golubchik [ serg ]
Status	In Testing [ 10301 ]	Stalled [ 10000 ]

Sergei Golubchik made changes - 2024-01-23 23:26

Fix Version/s		11.5 [ 29506 ]
Fix Version/s	11.4 [ 29301 ]

Sergei Golubchik made changes - 2024-02-03 10:17

Fix Version/s		11.4 [ 29301 ]
Fix Version/s	11.5 [ 29506 ]

Sergei Golubchik made changes - 2024-02-04 08:28

Priority

Critical [ 2 ]

Blocker [ 1 ]

Sergei Golubchik made changes - 2024-02-05 10:16

Priority

Blocker [ 1 ]

Critical [ 2 ]

Sergei Golubchik made changes - 2024-02-05 10:16

Fix Version/s		11.4.1 [ 29523 ]
Fix Version/s	11.4 [ 29301 ]
Resolution		Fixed [ 1 ]
Status	Stalled [ 10000 ]	Closed [ 6 ]

Daniel Black made changes - 2024-03-11 22:47

Link

This issue causes ~~MDEV-33639~~ [ ~~MDEV-33639~~ ]

Hartmut Holzgraefe made changes - 2024-05-04 20:01

Link

This issue relates to MXS-4102 [ MXS-4102 ]

MariaDB Server

validate ssl certificates using client password

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration