I'm not Aki but hope you don't mind...

On Wed, Apr 17, 2019, at 10:42 PM, TG Servers via dovecot wrote:

Hi,

MariaDB documentation says it accepts OpenSSL cipher strings in its ssl_cipher parameters like ssl_cipher="TLSv1.2".
This is also mentioned when creating or changing users in terms of setting this with the REQUIRE CIPHER parameter like CREATE USER ... REQUIRE CIPHER 'TLSv1.2'...
So this is all very nice and also working but sadly whith a connection string from dovecot it is not working anymore.
If you set the user only on REQUIRE SSL, the ssl connection and everything is working fine between dovecot and mariaDB.
But when you set REQUIRE CIPHER 'TLSv1.2' in mariaDB and use ssl_cipher=TLSv1.2 in the connection string from dovecot you get the following errors, it does not account the various ciphers of TLSv1.2 but rather expects TLSv1.2 somehow.

[Note] X509 ciphers mismatch: should be 'TLSv1.2' but is 'DHE-RSA-AES256-GCM-SHA384'

A good cipher is sent but the cipher cannot be TLSv1.2 of course :)
But no one will put in explicit ciphers there as this is dangerous in my eyes, people forget updating... Also this is misbehaviour or misdocumented.
The thing is now where to address this. Dovecot or MariaDB.
As dovecot seems to use a good cipher and MariaDB expects a TLSv1.2 string rather than a cipher out of TLSv1.2 I would say mariaDB but am not sure.

Maybe Aki could say something to it, would be great.

Thanks!

The docs from mariaDB to this are here :
https://mariadb.com/kb/en/library/create-user/

https://mariadb.com/kb/en/library/securing-connections-for-client-and-server/

But but but...

TLSv1.2 is not a cipher, it's a protocol.

Maria DB docs say the settings excepts a list of ciphers or a protocol name:

https://mariadb.com/kb/en/library/ssltls-system-variables/#ssl_cipher

In in other software it's common to have two distinct settings, one for protocol and one a cipher "pattern".

Maybe you could try something like this:

kECDHE+CHACHA20:kECDHE+AESGCM

ChaCha / Poly and AES GCM are TLS 1.2 + only ciphers.

This will not include AES CBC which exist with variations in both 1.0 to 1.2, but if you're security conscious, you probably don't want to use CBC anyway.

Or you could match just 1.2 versions with - I think - AESCBC+SHA384:AESCBC+SHA256. This will leave out AES CBC SHA1 which are in 1.0 - 1.1.

And now Aki can correct me :)

-- K