[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 ]

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}

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 ]

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 ]

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)

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 ]

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 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