Azure Ends TLS 1.0/1.1 Support: Key Script and Query
Many parties have recently contacted me regarding TLS support. The intention is to extract from Microsoft Sentinel findings or reports of all the old versions of Azure services TLS. In order to understand where old versions are, where new versions are, and what the next steps could be. This time, it’s not about attacking or investigating the cloud… So, once I checked this issue, I saw that it could raise some problems, but after all, it’s another standard task.
Those who have Microsoft Sentinel well configured with all the required Platform + Resource logs will find themselves in a situation where they can extract all the logs from Microsoft Sentinel. Most of the time, this is not the case. Moreover, most Azure Diagnostic logs in Microsoft Sentinel are not required or directly contribute to security incidents. Therefore, many organizations do not collect these logs.
Also, TLS support may not be found in all Azure sub-components, so a situation may arise where a specific component, for example, Azure SignalR Service, has a log that is not fully activated. Therefore, it is not possible to output information about TLS.
Another situation is when there are logs, but a message like the following can still be received: Not directly applicable (managed by service). In such situations, the TLS version is inside the components, so extracting it may be more complicated.
The following article, “Azure Services to End Support for TLS 1.0/1.1: What You Need to Know,” discusses the Azure service to End Support for TLS 1.0 and 1.1 and how to handle them with PowerShell and Resource Graph Explorer. It’s a quick and dirty blog post with the script and query to assist with TLS.
TLS Matter in Azure
The Azure services and its security options are constantly changing, as are the standards that keep our data safe. Microsoft recently announced they’re ending support for TLS 1.0 and TLS 1.1 across all Azure services by October 31, 2024. This means upgrading your services to more secure encryption standards, like TLS 1.2, to protect your data and ensure everything runs smoothly. In this post, we’ll look at how you can use Azure Policy to easily enforce these changes across your cloud environment.
In Azure, TLS is critical for securing connections to services like Azure App Service, Azure SQL Database, Azure Storage Accounts, and many others. Imagine your application sending sensitive customer data to your database in the cloud—without TLS, that data could be intercepted or compromised. Older versions of TLS, like 1.0 and 1.1, have known security weaknesses that hackers can exploit, making it risky to rely on them.
That’s why Microsoft requires all Azure services to use TLS 1.2 or newer by October 2024. TLS 1.2 provides better encryption, protecting your customers and business from evolving threats. Ensuring that your Azure resources are set to use TLS 1.2 means you can keep your services running securely without worrying about compromised data.
Key Points About the Change
- Support Ends on October 31, 2024: On this date, Microsoft will officially deprecate TLS 1.0 and TLS 1.1 for all Azure services. Any connections relying on these outdated versions will no longer be supported.
- TLS 1.2 as the Minimum Standard: TLS 1.2 will become the minimum required version for secure connections across Azure services, providing better encryption and improved security.
- Industry-Wide Trend: This deprecation is not unique to Microsoft; it reflects an industry-wide push to enhance security standards. Many major technology providers have stopped supporting TLS 1.0 and TLS 1.1 to mitigate vulnerabilities like BEAST, POODLE, and downgrade attacks.
Why This Matters
This change impacts all services using TLS for secure communication on Azure, including Azure App Service, Azure SQL Database, Azure Storage Accounts, and more. If any of your services or applications still use TLS 1.0 or TLS 1.1, they must be updated to maintain secure connectivity.
Failure to update could lead to broken connections, data integrity risks, or even complete inaccessibility of Azure services. Organizations must identify where older versions of TLS are still being used and ensure compatibility with at least TLS 1.2.
Steps to Take to Prepare for the Change
- Identify Affected Services: Start by auditing your Azure resources to identify services or applications still using TLS 1.0 or TLS 1.1. This can often be done using Azure Policy or network monitoring tools.
- Update Your Applications: If available, modify your applications to use TLS 1.2. This may involve updating application settings, middleware, or libraries that manage network connections.
- Testing: Test your applications after the upgrade to ensure they function correctly using TLS 1.2 or higher. Testing in a sandbox environment can help identify potential issues before deploying them in production.
- Enforce TLS 1.2: Where possible, enforce only TLS 1.2 or newer versions at the server level to ensure clients operate with adequate security.
Microsoft’s Guidance and Resources
Microsoft has provided detailed guidance to assist organizations in preparing for the transition. You can find official documentation and recommendations for upgrading to TLS 1.2 here.
Additionally, Azure offers tools such as Azure Policy to enforce compliance for TLS configurations across your resources. Utilizing these tools can help you meet the requirements well before the deadline.
The end of support for TLS 1.0 and TLS 1.1 on Azure is a critical step toward enhancing cloud security. Ensuring all your services comply with TLS 1.2 or above by October 31, 2024, is crucial to maintaining secure, reliable communications for your applications and services. Take the necessary steps to upgrade your systems, test compatibility, and enjoy more modern cryptographic standards’ security and performance benefits.
Are You Ready for the Deadline? Organizations must promptly avoid service disruptions after October 31, 2024. Make this transition a priority to continue leveraging Azure’s robust cloud infrastructure securely and efficiently. If you need more detailed information or support in making these changes, visit Microsoft’s official guidance page or consult your Azure support representative.
Not all TLS Configured Equal
You can extract the required information, including the TLS versions, with Microsoft Sentinel, Azure Resource Graph Explorer, and PowerShell. Still, it’s essential to know that not all Azure components have TLS configurations that are available to us. This means you should know which components you’ve got, their TLS version, settings, etc.
The supported Azure services in the following query and powershell script are for the following ones:
- Azure App Service
- Azure Storage Accounts
- Azure SQL Database
- Azure Key Vault
- Azure Application Gateway
- Azure Front Door
- Azure API Management
- Azure Load Balancer
- Azure Virtual Network Gateway
- Azure SignalR Service
- Azure Redis Cache
- Azure Service Bus
- Azure Kubernetes Service
Note: If you found an additional service, you can put a note in my X account so I can add it to the scrip/query.
Azure Resource Graph Explorer
To generate a TLS report or findings for various Azure services using Azure Resource Graph Explorer, you can utilize queries to audit the current settings and configurations of TLS across different Azure services. Azure Resource Graph allows you to gather details at scale from multiple subscriptions.
resources
| where type in (
‘microsoft.web/sites/config’,
‘microsoft.storage/storageaccounts’,
‘microsoft.sql/servers’,
‘microsoft.keyvault/vaults’,
‘microsoft.network/applicationgateways’,
‘microsoft.cdn/profiles/endpoints’,
‘microsoft.apimanagement/service’,
‘microsoft.network/virtualnetworkgateways’,
‘microsoft.signalrservice/signalr’,
‘microsoft.cache/redis’,
‘microsoft.servicebus/namespaces’,
‘microsoft.containerservice/managedclusters’
)
| extend TlsVersion = case(
type == ‘microsoft.web/sites/config’, properties.minTlsVersion,
type == ‘microsoft.storage/storageaccounts’, properties.minimumTlsVersion,
type == ‘microsoft.sql/servers’, properties.minimalTlsVersion,
type == ‘microsoft.keyvault/vaults’, ‘Not directly applicable (managed by service)’,
type == ‘microsoft.network/applicationgateways’, properties.sslPolicy.minProtocolVersion,
type == ‘microsoft.cdn/profiles/endpoints’, properties.tlsSettings.protocolType,
type == ‘microsoft.apimanagement/service’, tostring(properties.protocols),
type == ‘microsoft.network/virtualnetworkgateways’, tostring(properties.vpnClientConfiguration.vpnClientProtocols),
type == ‘microsoft.signalrservice/signalr’, properties.tls.minimalTlsVersion,
type == ‘microsoft.cache/redis’, properties.sku.family, // Redis may not directly expose TLS version
type == ‘microsoft.servicebus/namespaces’, properties.minimumTlsVersion,
type == ‘microsoft.containerservice/managedclusters’, ‘TLS managed by individual deployments’,
‘Unknown’
)
| project ResourceType = type, ResourceName = name, Location = location, TlsVersion
The query can be found here.
PowerShell
You can find the script here.
Below is a report.
Microsoft’s TLS enforcement strategy across Azure services aims to enhance data security and protect against outdated protocols like TLS 1.0 and 1.1 vulnerabilities. Azure users must ensure their configurations align with these standards, primarily enforcing TLS 1.2 or higher to maintain compliance and secure communication across their cloud environments.
Some Azure services allow customers to configure the TLS versions they wish to enforce. For instance, Azure App Service will enable customers to set a minimum TLS version, typically supporting TLS 1.2, to secure their applications effectively. Azure Storage Accounts also provide similar capabilities, where users can enforce TLS 1.2 to ensure secure data transmission. In the case of Azure SQL Database, administrators can configure the minimal TLS version for secure database connections, with TLS 1.2 being the standard enforced version. Similarly, Azure Application Gateway and Azure Front Door offer SSL policy settings, allowing enforcing TLS 1.2 while deprecating older versions to secure web traffic.
What about mitigation? Because each service behaves differently, you should create various policies for them. For example, Enforce a minimum required version of Transport Layer Security (TLS) for requests to a storage account.
More resources
