Bug #106852 | Cannot connect using named pipe on windows if the connection was the first | ||
---|---|---|---|
Submitted: | 28 Mar 2022 12:38 | Modified: | 11 Apr 2022 2:00 |
Reporter: | William Tang | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: Connection Handling | Severity: | S2 (Serious) |
Version: | 8.0.28 | OS: | Windows (Windows 11 Pro (build 22000.556)) |
Assigned to: | CPU Architecture: | x86 (x64) | |
Tags: | named pipe |
[28 Mar 2022 12:38]
William Tang
[28 Mar 2022 13:17]
MySQL Verification Team
Hello Tang William, Thank you for the bug report. Verified as described. Regards, Ashwini Patil
[7 Apr 2022 8:20]
Daniel Blanchard
Posted by developer: This appears to be correct behaviour to me: see the documentation at https://dev.mysql.com/doc/dev/mysql-server/latest/page_caching_sha2_authentication_exchang... When a named pipe connection is used for the first connection for a particular user (since the MySQL server started), the server has not cached the password for that user and thus attempts a full authentication exchange with the client. The full authentication exchange cannot be performed over a named pipe as it is not a secure channel, hence the client error message. When a different connection has already successfully connected with the server for the user, attempting to connect for the same user over a named pipe will succeed via the "fast authentication" route as the cached password for the user is already present on the server. In order to successfully connect over a named pipe for the first time, one can use the --get-server-public-key mysql command line option, so that the full authentication exchange between the client and server can be achieved without sending the password in plaintext over the insecure named pipe connection.
[11 Apr 2022 2:00]
William Tang
Hi, Daniel Blanchard. As the default behavior, it's very confusing to most of the users. And why mysql cannot establish secure connection using local method like named pipe while tcp has no such problem? Is it because tcp fetch the public key from the server by default? If so, can you make named pipe do the same thing by default?