TLS 1.0 Vulnerabilites on SQL databases

Question

The remote service accepts connections encrypted using TLS 1.0. TLS 1.0 has a number of cryptographic design flaws. Modern implementations of TLS 1.0 mitigate these problems, but newer versions of TLS like 1.2 and 1.3 are designed against these flaws and should be used whenever possible. As of March 31, 2020, Endpoints that aren’t enabled for TLS 1.2 and higher will no longer function properly with major web browsers and major vendors. PCI DSS v3.2 requires that TLS 1.0 be disabled entirely by June 30, 2018, except for POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits. We have enabled TLS 1.3 for the SQL server hosting the database in Azure, but still get the vulnerability with our Vulnerability scans. Also the Azure hosted databases are affected with the Cipher SWEET32 vulnerability: The remote host supports the use of SSL ciphers that offer medium strength encryption. Nessus regards medium strength as any encryption that uses key lengths at least 64 bits and less than 112 bits, or else that uses the 3DES encryption suite. Note that it is considerably easier to circumvent medium strength encryption if the attacker is on the same physical network. Please advise on how to fix these 2 vulnerabilities or a ETA of a fix from Microsoft.

Answer 1

Azure SQL Database has a shared Control Plane due to which Azure cannot selectively turn off specific version of TLS or weak cipher suites. When Azure customers run scanners against Azure infrastructure, they will see these flagged and it is by design. Vulnerability scanners will show something like:

TLS 1.0 FOUND

TLS 1.1 FOUND

• TLS 1.2 with Weak Cipher Suite (SWEET32).

Azure initially announced deprecation of TLS < 1.2 by October 31st 2024 but Azure extended support for TLS 1.0 and TLS 1.1 to August 31, 2025 as you can read here. That should eliminate majority of the weak ciphers. Additionally, Azure is working on adding TLS 1.3 to Minimal TLS Version so customer can use it to overcome Sweet32 vulnerability but there is no official ETA.

As of today, Azure infrastructure does support TLS 1.3 connectivity even though it is not added as an option to Minimal TLS Version.

Hope this helps.

Answer 2

Hi,

The results you are seeing from vulnerability scans are normal. It is likely the vulnerability scanner is running its tests against the Azure SQL Gateway(s). This is not the same as fully establishing an authenticated connection to Azure SQL cluster (via Gateway or direct) using TLS 1.X version. For example, a better test would be to try to connect using SQL Server Management Studio from a PC that is capable of maximum TLS 1.1.

Azure SQL is a multi-tenant Platform-as-a-Service (PaaS) and as a result you are not connecting to a public IP address for a dedicated instance of SQL Server. Instead it is shared by many different customers, some of which may allow TLS 1.0 or 1.1.

Since the service still supports TLS 1.0/1.1 (if customer allows it) the components will still show as supporting these lower versions when performing the type of tests in common vulnerability scanners. Conversely if you attempt to fully connect to your logical Azure SQL Server using a TLS version lower than configured minimum you should receive an error and the connection fail.

Please reference article below for more details on Azure SQL Database connectivity architecture:

Azure SQL Database and Azure Synapse Analytics connectivity architecture

https://learn.microsoft.com/en-us/azure/azure-sql/database/connectivity-architecture?view=azuresql#connectivity-architecture

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP