How to discover the attempts of using TLS 1.0 and 1.1 after upgrading the SSL policy to 20220101 version in app gateway?

Hi @Samuel Lee,

Welcome to the Microsoft Q&A Platform. Thank you for posting your query here. We are looking into it and reviewing the documents and will get back to you soon.

Regards,

Sai Prasanna.

Hi @Samuel Lee,

Greetings!

We understand that you want to effectively monitor and identify failed connection attempts due to clients attempting to use legacy TLS versions (such as TLS 1.0 or 1.1) with your upgraded Azure Application Gateway SSL policy (20220101).

1. Enable diagnostic logging for your Azure Application Gateway. This will capture detailed information about incoming requests, including connection attempts that fail due to unsupported TLS versions.
2. You can also store these logs after collecting into Azure Monitor, Log Analytics, or a storage account for further analysis.   
3. Go to Application gateway > Monitoring > Diagnostic Settings > In diagnostic settings choose the logs you want to collect, like ApplicationGatewayAccessLog, ApplicationGatewayPerformanceLog, ApplicationGatewayErrorLog.
4. You can choose ApplicationGatewayAccessLog and it contains all the logs to view Application Gateway access patterns and analyze important information. This includes the caller's IP, requested URL, response latency, return code, and bytes in and out. For your reference: https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/agwaccesslogs
5. You can check the Backend Health status of your Application Gateway configuration. If the backend servers are receiving requests marked as failed due to TLS issues, this can provide insights into underlying TLS compatibility problems. For your reference: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-backend-health-troubleshooting#how-to-check-backend-health
6. Utilizing Azure Monitor along with Log Analytics can provide deeper insights into your access logs. You can also set up alerts in Azure Monitor to notify you when certain thresholds are met, such as a spike in error responses, which could imply that clients are failing to connect using unsupported TLS versions. For your reference: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-diagnostics

Kindly let us know if the above helps or you need further assistance on this issue.

Regards,

Sai Prasanna.

Hi @Samuel Lee,

Greetings of the day!

I would like to follow up with the thread.

Could you please go through the last comment and provide us the required information to drive the thread further.

If you need any further assistance, please don't hesitate to reach out to us. We are happy to assist you.

Regards,

Sai Prasanna.

Hi Sai,

We performed a test in our environment (Upgrade to 20220101 and try to connect via 1.0 and 1.1. But we could not see the TLS connection errors from ApplicationGateway Access log. What we can see only the client IP address with HTTP error code 400 without any cipher information from the log. Is there any better way that can tell what cipher the legacy clients trying to connect with?

Best regards,

Samuel

Hi @Samuel Lee,

Greetings!

A quick way to determine what TLS version will be requested by various clients when connecting to your online services is by referring to the Handshake Simulation at Qualys SSL Labs. This simulation covers client OS/browser combinations across manufacturers.

Reference: https://learn.microsoft.com/en-us/security/engineering/solving-tls1-problem#figure-1-security-protocol-support-by-os-version

Please refer to the below document for a detailed example showing the TLS protocol versions negotiated by various simulated client OS/browser combinations.

Refer: https://learn.microsoft.com/en-us/security/engineering/solving-tls1-problem#appendix-a-handshake-simulation

If not already complete, it is highly recommended to conduct an inventory of operating systems used by your enterprise, customers and partners (the latter two via outreach/communication or at least HTTP User-Agent string collection). This inventory can be further supplemented by traffic analysis at your enterprise network edge. In such a situation, traffic analysis will yield the TLS versions successfully negotiated by customers/partners connecting to your services, but the traffic itself will remain encrypted.

Kindly let us know if the above helps or you need further assistance on this issue.

Regards,

Sai Prasanna.