Bug #92750 Request to improve logging of failed connections
Submitted: 11 Oct 2018 11:59 Modified: 15 Oct 2018 13:19
Reporter: James Lawrie Email Updates:
Status: Unsupported Impact on me:
None 
Category:MySQL Server Severity:S4 (Feature request)
Version:5.7.22 OS:Any
Assigned to: CPU Architecture:Any

[11 Oct 2018 11:59] James Lawrie
Description:
If a connection is aborted or rejected for any reason it would be much easier to diagnose issues if the relevant data could be logged into the server log.  

Any update to performance_schema.host_cache errors should have the option to print the related error to the server log.

How to repeat:
Start MySQL with skip-ssl and attempt to connect with SSL:

$ mysql --ssl --host 10.0.0.71
ERROR 2026 (HY000): SSL connection error: SSL is required but the server doesn't support it

Strace shows the client requests capabilities and then just aborts:
recvfrom(3, "T\0\0\0\n5.7.22-22-57-log\0)\0\0\0s%\37q\r\32\10\\\0\377\367\10\2\0\377\201\25\0\0\0\0\0\0\0\0\0\0!N\nh+CTvPr\10P\0mysql_native_password\0", 16384, 0, NULL, NULL) = 88
shutdown(3, SHUT_RDWR)                  = 0

Server side debug shows a handshake error:
T@44: | | | | | | | error: error: 1158  message: 'Got an error reading communication packets'
T@44: | | | | | | | >mysql_audit_acquire_plugins
T@44: | | | | | | | <mysql_audit_acquire_plugins 1125
T@44: | | | | | | | >THD::raise_condition
T@44: | | | | | | | | >query_cache_abort
T@44: | | | | | | | | <query_cache_abort 1234
T@44: | | | | | | | | >set_error_status
T@44: | | | | | | | | <set_error_status 467
T@44: | | | | | | | | >alloc_root
T@44: | | | | | | | | | enter: root: 0x7fd81c00d9b8
T@44: | | | | | | | | | >my_raw_malloc
T@44: | | | | | | | | | | my: size: 2048  my_flags: 1040
T@44: | | | | | | | | | | exit: ptr: 0x7fd81c01c5d0
T@44: | | | | | | | | | <my_raw_malloc 219
T@44: | | | | | | | | | exit: ptr: 0x7fd81c01c600
T@44: | | | | | | | | <alloc_root 304
T@44: | | | | | | | | >alloc_root
T@44: | | | | | | | | | enter: root: 0x7fd81c00d9b8
T@44: | | | | | | | | | exit: ptr: 0x7fd81c01c788
T@44: | | | | | | | | <alloc_root 304
T@44: | | | | | | | <THD::raise_condition 1822
T@44: | | | | | | <my_message_sql 2863
T@44: | | | | | <my_error 211
T@44: | | | | | info: client capabilities: 90
T@44: | | | | | info: client_character_set: 8
T@44: | | | | | >my_error
T@44: | | | | | | my: nr: 1043  MyFlags: 0  errno: 11
T@44: | | | | | | >my_message_sql
T@44: | | | | | | | error: error: 1043  message: 'Bad handshake'

But nothing is logged.  

For another test, start MySQL with tls-version 1.2 and try to connect with 1.1:
mysql> SHOW VARIABLES LIKE 'tls_version';
+---------------+---------+
| Variable_name | Value   |
+---------------+---------+
| tls_version   | TLSv1.2 |
+---------------+---------+
1 row in set (0.06 sec)

mysql> SHOW VARIABLES LIKE 'log_error_verbosity';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| log_error_verbosity | 3     |
+---------------------+-------+
1 row in set (0.06 sec)

mysql> exit;
Bye
# mysql -h10.0.0.71 --tls-version=TLSv1.1
ERROR 2026 (HY000): SSL connection error: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

Server debug:
T@21: | | | | | | >report_errors
T@21: | | | | | | | error: OpenSSL: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:640:

T@21: | | | | | | | error: SSL_get_error: 5
T@21: | | | | | | | info: socket_errno: 0
T@21: | | | | | | <report_errors 50
T@21: | | | | | | error: SSL_connect/accept failure
T@21: | | | | | <ssl_do 447
T@21: | | | | | error: Failed to accept new SSL connection
T@21: | | | | | >my_error
T@21: | | | | | | my: nr: 1043  MyFlags: 0  errno: 71
T@21: | | | | | | >my_message_sql
T@21: | | | | | | | error: error: 1043  message: 'Bad handshake'  

There is still nothing logged to the server.

Suggested fix:
Aborted clients for any reason (eg. SSL handshake error, credentials not provided) should be loggable to the error log. Any failed connections should have the option to increase verbosity in the error log.
[11 Oct 2018 17:33] Tianshi Wang
Since more and more teams are using Kubernetes or similar, client side debugging is less preferable.
[15 Oct 2018 13:19] MySQL Verification Team
Hi,

Thank you for your report on the feature request.

I am sorry that I have to inform you but, this feature request can not be accepted since the more verbose error messages on the both client and server side would make the entire system less resistant to the cracking attacks. Security is more important then verbosity.