Authentication failed because the remote party sent a TLS alert: 'ProtocolVersion' #1407
Comments
|
Normally I'd say this sounds like it's probably more related to your client OS or .NET version than MySqlConnector. However, I would expect that to consistently fail. If it only fails occasionally, there could be a client-side bug in falling back to a supported TLS version when connecting fails.
Enabling logging (at Debug or even Trace) level may provide some useful information about what's happening with the connection that throws an exception. https://mysqlconnector.net/diagnostics/logging/ |
|
Yes the intermittent nature of this issue is confusing me. I'll attempt to get some further details from logging. |
|
OK, some further info. It appears the ProtocolVersion error is because it falls back to TLS 1.1 which is no longer supported in Aurora MySQL 3.05.0. But why the initial attempt with TLS 1.3 fails, I don't yet know. As before, it works most of the time. Here's an example of one session that fails: Note that the previous session 2.313 (which is actually happening at the same time) works as expected: For more context, this is an ASP.NET Core app. |
|
What could be the cause of the failed negotiation (i.e. the initial issue)? Given it doesn't happen when TLS1.2 is used, that would rule out issues of connectivity or connection limits being hit. Maybe there's a bug somewhere in the MySqlConnector/ASP .NET Core/Windows Server/Aurora chain. Is it possible that it's related to threading? (e.g. something about the TLS1.3 implementation that only rears its head when multiple connections are being made) |
Did you show logs from the initial failure, or just from the retry? Is |
|
Yes DecryptError looks like the initial failure:
|
|
I'd like to eliminate steps 3-5 above: #1409 However, that won't fix the failure in step 2. My general advice is to add retry support (e.g., with Polly); networks and database connections are unreliable (e.g., packets can be dropped or a server may have a transient error such as too many existing connections), so it often is best to retry for a certain number of attempts or a certain duration before definitively failing and raising an error. |
|
Given both application server and database are in the same VPC, I would hope that reliability of network connections aren't to blame. If it was the case, why would switching to TLS1.2 "fix" the issue? I'm happy to test again when #1409 is resolved. |
|
I'm hitting this as well, also intermittently. Running MYSQL 8 community edition locally and connecting to it from local. |
|
@bgrainger I upgraded from 2.3.1 to 2.3.4 and the issue seems to be resolved. I no longer get any exceptions and can see in the logs that TLS1.3 connections are successfully made, .e.g. "Session 2.2044 connected TLS using Tls13 and TLS_AES_256_GCM_SHA384". So I suspect there was some bad code affecting the earlier versions when connecting to TLS 1.3, that only reared its head sometimes. @mikethea1 Can you re-test with 2.3.4? |
|
I'm still seeing some DecryptError failures in my logs with MySqlConnector 2.3.4: I'll see if I can get some more information |
Here's the debug-level logs from a failing connection:
|
|
Here's an example with verbose logging. Not much new information. I don't believe this is a networking/transmission error given both the database server and the application server are in the same AZ in the VPC. Client is ASP.NET Core 6.0, MySqlConnector 2.3.5 So the newer versions of MySqlConnector have resolved the secondary ProtocolVersion failure, but not the initial DecryptError failure. As originally reported, this is a sporadic failure.
|
|
The Cloudwatch RDS error log shows the following when the DecryptError occurs: 2024-02-27T22:51:53.787124Z 8833 [Note] [MY-010914] [Server] Bad handshake |
|
Possibly related to #1448, but that bug is |
|
Possibly related, but note in my case the issue is somehow related to TLS1.3 Modifying the Aurora parameter group to only allow TLS1.2 "fixes" the problem |
|
We are getting the same issue with azure web app and azure mysql on 2 servers, we are on Net 6, had the issues since core 3.1. It will be fine for months, then it will happen, have to restart our servers then ok anywhere from a month to a few months, its just random. We had it a week ago, and its come back already this time around. SSL Authentication Error MySqlConnector.MySqlException I changed the connection strings to force 1.2 but that didnt seem to resolve anything. {"assembly":"MySqlConnector, Version=2.0.0.0, Culture=neutral, PublicKeyToken=d33d3e53aa5f8c92","method":"MySqlConnector.Core.ServerSession+d__102.MoveNext","level":0,"line":1571,"fileName":"/_/src/MySqlConnector/Core/ServerSession.cs"} |
|
@bgrainger Thanks for the info, I am not on that version, Ill update to that and see how I go, that issue does seem to be mine so looks good, thank you. |
|
Issue appears to be resolved in 2.3.4. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Software versions
MySqlConnector version: 2.3.1
Application running on EC2 Windows Server 2022 10.0.20348 N/A Build 20348
Server type (MySQL, MariaDB, Aurora, etc.) and version: AWS Aurora MySQL 3.05.0
.NET version: 6.0.23
Describe the bug
I'm connecting to an Aurora cluster with a single instance.
Occasionally there is an exception when opening connections:
Authentication failed because the remote party sent a TLS alert: 'ProtocolVersion'.My connection string is as follows:
I was previously on MySQLConnector 2.2.7 but have upgraded to 2.3.1 and the issue still exists.
This issue seems to be related to TLS v1.3. If I change the cluster parameter group "tls_version" setting to "TLSv1.2" then the issue doesn't occur. If I set it to "TLSv1.3" or leave it as default (which is both 1.2 and 1.3) then I get the occasional exception.
I am not certain this issue is MySqlConnector-related, but I'm not sure how to pursue it further. Is there some debug I can enable?
Exception
The text was updated successfully, but these errors were encountered: