We have a .NET 4.7.1 ASP.NET MVC application running on Windows Server 2012 R2.
In the Registry, we set the "Enabled" properties to zero (FALSE) for the following keys:
HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.0\Client
HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.0\Server
However, after rebooting, we found that whilst our application could pull data securely from a 3rd party "Service Reference", it was unable to pull data securely from another 3rd party "Web Reference".
Reverting the "Client" Enabled property to 4294967295 (true) (and rebooting) solved the issue.
We're informed that the web-reference concerned supports TLS 1.0, 1.1, and 1.2, and that other clients are able to consume data using TLS 1.1/1.2.
The MVC application is set to use the server settings (protocols are not hard-coded).
Related
We have a web app hosted in an Azure Server (using api in an Azure Server). For security purposes we'd like to know if the server is under tls 1.2 (I suppose for a non-cloud server we'll just have to see in regedit to know it).
I've seen topics on how to disabled ssl 3 from an azure server see at :
https://azure.microsoft.com/fr-fr/blog/how-to-disable-ssl-3-0-in-azure-websites-roles-and-virtual-machines/
I suppose to enable tls 1.2 we'll have to do this kind of things ...
So my questions are :
- How to know if the azure server is under tls 1.2
- if not, how to set the azure server to tls 1.2
Thanx for your help.
As of today 2018-04-30, you can modify your site to only serve TLS 1.2 and up by going to your app service, then TLS/SSL settings, then setting your minimum TLS Version.
So after the good advice of Panagiotis, we can see this in Chrome/F12 Security, it is said that we're under TLS 1.2, but the cypher is obsolete, the question now would be how to put an up to date cypher, any idea ?
As Panagiotis Kanavos correctly points out:
Azure Websites has disabled SSL 3.0 for all sites by default to protect our customers from the vulnerability mentioned before. Customers no longer need to take any action to disable SSL 3.0 in Azure Websites.
But, here's some specific answers to your questions:
How to know if the azure server is under TLS 1.2?
Check your site with: https://www.ssllabs.com/ssltest/index.html (search for "protocol" and you'll find a list of SSL/TLS versions allowed/disallowed).
If not, how to set the azure server to TLS 1.2?
Start here: How do I disable SSL fallback and use only TLS for outbound connections in .NET? (Poodle mitigation) (requires .NET 4.6).
Then combine with this: https://www.leowkahman.com/2017/07/04/how-to-disable-tls-1-0-on-an-azure-app-service/ (not supported).
Or this: https://learn.microsoft.com/en-au/azure/app-service-web/app-service-app-service-environment-custom-settings (supported).
There are caveats to this setting. Apparently, its not just this setting that controls the transport level outbound communication. We have a situation where we are communicating with a third-party API which is only supporting TLS 1.2 and communication fails with either of this Minimum TLS version 1.0,1.1 and 1.2 on Azure App Service. The hosted app is a .Net Web API on Framework 4.7. So, we had to make this change in Global.asax --> Application_Start so the code tries to communicate with 1.2 and if it fails it tries with 1.1 and then system default.
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls | SecurityProtocolType.SystemDefault;
I am trying to connect and send a message to azure service bus queue using the following code
var connectionString = "<Your connection string>";
var queueName = "<Your queue name>";
var client = QueueClient.CreateFromConnectionString(connectionString, queueName);
var message = new BrokeredMessage("This is a test message!");
client.Send(message);
This is the same code they have on their site as an example.
But while connecting, it gives an SSPI ERROR with an inner exception of 'The client and server do not possess a common algorithm'.
Also, I have disabled TLS 1.0 and SSL 3.0 in my system. Is it because of that.
Can someone help me understand what is wrong here?
The client and server do not possess a common algorithm
That's not a TCP layer problem. That's higher up in the TLS handshake and it means just that. The two parties (client and server) could not agree on a common cipher suite and the handshake failed.
Run your client's host through SSLLab's browser test (even if it's not a browser):
https://www.ssllabs.com/ssltest/viewMyClient.html
Then run the Service Bus endpoint through the server test page:
https://www.ssllabs.com/ssltest/
Compare results and enable at least one cipher suite in your client that matches what the TLS stack on the Service Bus endpoint accepts.
You should also simply try doing:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
..since you've disabled TLS 1.0 and i'm no longer sure what your .NET now defaults to, so explicitly setting the protocol version is the natural way to go.
TLS 1.2 was released back in 2008. You can be sure Azure supports it for all services, globally - check your own Service Bus namespace here!
(same story for 935x/TCP).
It's not enough to support TLS 1.2, your host must have at least one common cipher suite with the server -- use this to check your host:
https://github.com/snobu/get-schannel-ciphers (.exe under /Release/)
We encountered the exact same issue when we disabled TLS 1.0 and 1.1 (we used https://docs.nwebsec.com/projects/AzureStartupTasks/en/latest/ and also added
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
in Global.asax under Application_Start).
We opened a ticket with Microsoft support and found out that Azure Service Bus needs to be upgraded to .Net Framework 4.6.2 in order to support TLS 1.1 and TLS 1.2. Here are the details:
Service Bus relies on the underlying SSLStream class for secure communication for NetEventRealyBinding.
In WCF included in the .Net Framework 4.5.2, SSLStream only supports SSL 3.0 and TLS 1.0.
The WCF version in .Net Framework 4.6.2 supports TLS 1.1 and TLS 1.2 for SSLStream.
The Service Bus Service will need to be updated to use .Net Framework 4.6.2. Currently Service Bus uses OSFamily 4 https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-guestos-update-matrix#family-4-releases which has .Net Framework 4.5.2. Current plans to upgrade to .Net Framework are slated for middle of 2017.
I'll update this answer once I hear more from Microsoft.
UPDATE 2017-03-21:
Microsoft sent this workaround, which fixed the issue and allowed our code to work with TLS 1.2.
In the PowerShell script you currently use to set up TLS 1.2, add the following line. On .Net Framework 4.5.2 this will force SslStreams to use Tls 1.0/1.1/1.2. But since your machine allows only TLS 1.2, that will be used.
UpdateRegistryKey "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" "SchUseStrongCrypto" 1 "DWORD"
In you the startup of your code add the following line, and rebuild and retest
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https;
I want to be able to disable the TLS 1.0 protocol and the RC4 cipher on an Azure website (or Web App) and I can't figure out if it's possible or not. (edit: I am aware that SSL 3.0 is disabled by default on Azure websites but I specifically want to disable TLS 1.0)
I know what registry settings to update but the problem of course is that I don't have access to the OS.
There's the NWebsec startup tasks that allow you to configure web roles (or cloud service) but my understanding is that this solution does not apply to web apps.
Is there any workaround?
Update Jan 2017
Microsoft have completed a feature whereby TLS1.0 can be disabled via App Service Environment configuration. It's possible to set your own ciphers through the Azure resource manager or change the cipher suite order.
Details are available on the Custom configuration settings for App Service Environments page.
Original answer:
The original answer was that it is not possible to configure anything in the Registry or SSL settings in Azure web apps.
Microsoft are aware of PCI compliance changes and will update the host machines that the web apps run on in their own time frame. They announced in January 2015 that they would starting making updates on 18th July 2015 that would result in an A grade for TLS/SSL endpoints for Auzre web apps on sites like http://ssllabs.com
It's likely that this will be an on-going issue as computing power increases and more vulnerabilities are discovered and hosted web apps must rely on Microsoft to keep their servers patched and up-to-date in a timely manner.
This link has some more background information on the changes Microsoft are making: https://social.msdn.microsoft.com/Forums/azure/en-US/50f1ab33-c22a-4629-951e-b7510f6b2cbe/upgrading-tlsssl-cryptography-for-azure-web-apps?forum=windowsazurewebsitespreview
And this link also tracks the feature request that asks MS to disable insecure ciphers in Web apps:
http://feedback.azure.com/forums/169385-web-apps-formerly-websites/suggestions/7091994-disable-insecure-ciphers-in-azure-websites?page=2&per_page=20
If registry access and specific control of these settings is a requirement, the Azure options are Cloud Service WebRoles or IAAs VMs.
Vote to get MS to disable TLS 1.0
I am having an same issue when trying to run SharePoint Foundation 2010, and I am using the NTLM Windows Authentication Provider. We are running IIS 7.5, and we have a dev SharePoint site set up on another server, using the exact same authentication, but for some reason, the site on our prod server throws the error "No credentials are available in the security package." This fails using all browsers, and it fails when I run the site from the server directly as well as from any client machine. We have Windows Server 2008 R2 Standard on both machines.
I've checked that all the security settings for the SharePoint app pool as well as the SharePoint Web Services pool matches our dev server's settings, and they all do.
Any ideas? Thanks.
It looks like Kerberos is failing on the server. I understand you are using NTLM but the message seems to be Kerberos. Could you please check Authentication provider on on the IIS? If Negotiate is at the top of the list move down and make ntlm as top provider
IIS - UnderAuthentication - > Providers
When windows Authentication is used , this error can come if Kerberos is not available or failing, upon checking Providers under Windows Authentication setting in IIS, i changed preference of Negotiate and moved it down , NTLM remained up and it fixed my issue
I have two applications hosted at IIS 7.5 on Windows 2008 Server R2. One application is hosting at .net framework 4.0 and other on framework 2.0. Both have Integrated and Classic values for Managed Pipeline Mode property of Application Pool.
Issue is, at client machine only one application is login at a time, if I login to 1st application 2nd gone to session timeout and vice verse.
Please help and suggest which configuration is require at IIS end.