[MXS-3665] Provide more feedback on TLS cipher mismatch Created: 2021-07-10 Updated: 2022-04-12 Resolved: 2022-03-08 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Core |
| Affects Version/s: | None |
| Fix Version/s: | 2.5.20, 6.2.4, 22.08.0 |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Hartmut Holzgraefe | Assignee: | markus makela |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Sprint: | MXS-SPRINT-152 |
| Description |
|
When getting a TLS "no matching cipher" error it would be nice to get log information about the set of ciphers offered by the clients and those supported by the maxscale instance, to make it more easy to figure out the problem on the Maxscale side. This would help in case of TLS connection problems without revealing any sensitive information to a potential client side attacker, as such an attacker could just try out ciphers one by one anyway, while a legitimate client running into this problem may have a harder time figuring out what to do (e.g. may only be able to figure out what ciphers the client application / connector actually offered by capturing TCP traffic ...) |
| Comments |
| Comment by markus makela [ 2022-03-02 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I'll see if we can provide some extra information in the REST API output about the TLS certificates themselves. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by markus makela [ 2022-03-04 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Wouldn't it be possible to see what the server (or MaxScale) offers using openssl s_client with the -starttls mysql option? This seems to provide the set of shared ciphers between the client and the host:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by markus makela [ 2022-03-07 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
After taking a second look at the APIs, I think there's one function in 1.0.2 that we can use: SSL_get_cipher_list. This should be enough to report an error on the info level whenever OpenSSL reports an error. However, this only displays the certificates MaxScale was using, not the ones the client offered. Using SSL_get_client_ciphers we can get the client ciphers but this also seems to only be present in OpenSSL 1.1.1. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by markus makela [ 2022-03-07 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Here's an example of what will be logged in 2.5.20 when there are no shared ciphers:
It's not that easy to read but it'll show you why it failed. The Client ciphers section is only logged for systems that use OpenSSL 1.1.1 or newer and only when MaxScale is acting as the server (i.e. TLS is used in listeners). For MaxScale <-> MariaDB communication this is not possible as the client always sends the cipher list and the server chooses which one to use. In this case the Client ciphers list is actually the Our ciphers list. |