Skip to content
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

TLS 1.2 will be enforced non IP-SSL hostnames if SNI header is not present in the SSL handshake request #104

Closed
JennyLawrance opened this issue Apr 24, 2018 · 0 comments

Comments

Projects
None yet
2 participants
@JennyLawrance
Copy link

commented Apr 24, 2018

As part of the Azure TLS 1.2 compliance initiative, Azure App Service now offers per site configuration for the minimum version of TLS to be used for a site. We recommend customers use TLS 1.2 as the minimum required version for the site for security reasons. Note that TLS 1.2 is also the maximum version you can negotiate with Azure App Service.

Clients using TLS 1.0 hitting an IP-SSL hostname, or clients using TLS 1.0 with an SNI extension header will be subjected to the checks of min-TLS version specified for the site.

A side effect of this change is that, if an SSL client arrives without the SNI header (https://en.wikipedia.org/wiki/Server_Name_Indication) on a non-IP SSL binding, then our system has to ensure that TLS 1.2 is used for the connection to ensure compliance.

If a client tries to negotiate TLS 1.0 over such a scenario, the request will fail with connection reset.

The work around for sites which require to support TLS 1.0 clients which could potentially make requests without SNI header is to add IP-SSL hostname bindings for the target web app.

@Azure Azure locked and limited conversation to collaborators May 3, 2018

@fabiocav fabiocav closed this Apr 9, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.