-
Notifications
You must be signed in to change notification settings - Fork 337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
yaSSL/Schannel TLS 1.2 workaround causing unintended TLS downgrade #1132
Labels
Comments
That is definitely not intentional. The intended way to avoid TLS fallback would be to specify |
lostatredrock
added a commit
to lostatredrock/MySqlConnector
that referenced
this issue
Feb 10, 2022
Change the logic used to determine when a connection attempt is failing due to a lack of support for TLS 1.2+ in yaSSL-based MySQL Server so that a downgrade no longer occurs if the user has explicitly configured supported TLS Version(s) in the connection string. Signed-off-by: Andrew Nagel <andrew.nagel@gmail.com>
lostatredrock
added a commit
to lostatredrock/MySqlConnector
that referenced
this issue
Feb 10, 2022
Change the logic used to determine when a connection attempt is failing due to a lack of support for TLS 1.2+ in yaSSL-based MySQL Server so that a downgrade no longer occurs if the user has explicitly configured supported TLS Version(s) in the connection string. Signed-off-by: Andrew Nagel <andrew.nagel@gmail.com> Signed-off-by: Andrew Nagel <andrew.nagel.ctr@dot.gov>
Fixed in 2.1.6. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Software versions
MySqlConnector version: 1.3.14 (issue also exists in latest version 2.1.5)
Server type (MySQL, MariaDB, Aurora, etc.) and version: MySQL 8.0.27
.NET version: 5.0.14
(Optional) ORM NuGet packages and versions: Pomelo.EntityFrameworkCore.MySql 5.0.3
Describe the bug
We have been experiencing connectivity issues in which our application server looses the ability to establish new connections to the database server. Reviewing the logs we see repeats of the message: "The server doesn't support the client's specified TLS versions."
Stepping back to the start of this connectivity issue we are seeing the message "Session1.944 failed negotiating TLS; falling back to TLS 1.1" logged as a warning.
Looking into the connector code I see that this is part of a work around to an issue establishing TLS 1.2 connections between a windows server a yaSSL based MySQL instance (comment). In this case our MySQL instance is OpenSSL based and we are experiencing an IOException due to an unknown cause (we are still investigating the cause of the IO Exception).
Stepping into the connect code the crtiteria for retry is here and the downgrade code is here . The effect of this is that if you are running a windows server and experience an IO Exception when establishing a new database connection your pool will permenatly fall back to TLS 1.1. As far as I can see there is no way to override this fallback. Specifying TLS 1.2 in the connection string will get overidden and specifying nothign (and leaving it to the OS) will also make the application subject to this downgrade.
In our case the downgrade crashed the application until restart because we disallow TLS 1.0 and 1.1 connections at the OS level on the app and db servers.
Exception
The fallback is initiated when this exception occurs:
which then leads to this exception occuring on all future connection attempts:
snipped to exclude internal code which can be anything requesting a DB connection
Expected behavior
There should be a way to override this behavior. I would think a seperate NotUsingYASSL flag would probably be the best way to acccomplish this without breaking the work around for users who do need the fallback.
Additional context
We are looking into the source of the IO Exception to try and work around the problem. But a single random IO Exception (which is not unheard of) should not disable TLS 1.2 permenantly.
The text was updated successfully, but these errors were encountered: