IBM Cloud will withdraw support to TLS 1.0 and 1.1 after March 1. In the page https://console.bluemix.net/docs/get-support/appsectls.html it says that if you try your url adding ".alt" after de subdomain and it works, then you will not have any problem. But in my case, it doesnt work, so it says that i should enable tls 1.2 but doesnt tell me how. Also, i have seen that in the "EEUU West" region there is no problem with TLS 1.2 support. Otherwise, in the "Germany" region you don't have support at first. Can you tell me how to enable TLS 1.2 in Germany region for any project? Thank you in advance.
The following information was provided by an IBM Cloud platform Architect:
If your application is hosted in Germany under the eu-de.mybluemix.net domain, then TLS 1.0 is already disabled for your application, and if your clients are able to connect to it successfully then you should be ok.
The eu-de.mybluemix.net domain does not offer the alternative alt.eu-de.mybluemix.net to test with because TLS 1.0 has always been disabled for eu-de. We will be removing TLS 1.1 from the eu-de.bluemix.net domain but it is very unlikely that your clients will be using that as that is very rare.
Related
I have an Azure Storage V2 account setup and I am trying to block TLS 1.0 and 1.1.
I have set the Minimum TLS version to 1.2 but when I test the storage account using SSL Labs or other tools to test the TLS versions that are supported they still report TLS 1.0 and 1.1 being enabled.
Below is a screenshot of the configuration from the Azure portal. I also checked in Powershell and the Minimum TLS version reported is TLS1_2. Have I missed something or could this be because of something else?
During my attempts to reproduce this in a browser for my support ticket I was able to verify that TLS 1.0 and 1.1 ARE being blocked but not at the Session/Presentation layer (I know some debate exists whether TLS is at layer 5/6), they are blocked at the Application layer. The Azure Storage host accepts the TLS 1.0 connection and then checks your account's settings and if the Minimum TLS version is not met it throws an HTTP 400 error stating the TLS version is not permitted.
For my purposes I will try to get this accepted by the auditors as this will continue to fail the TLS-testing sites but for any practical matter TLS 1.0/1.1 is blocked.
This is what Azure returns when you browse to the site with an unsupported TLS version:
And the GET HTTP Response is 400 -
To test this I found that you can force Firefox to a Minimum / Maximum TLS version and then test this in a browser. To configure Firefox to allow TLS 1.0 follow these steps (obviously remember to change this back after testing):
Go to about:config in the Firefox address bar
Set security.tls.version.enable-deprecated to true
Set security.tls.version.max to 1 (or 2 for TLS 1.1)
Set security.tls.version.min to 1
You can then test any site using TLS 1.0.
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;
In order to maintain PCI compliance, I need to have TLS v1.0 disabled. Is there anyway to do that (without paying for tech support)?
As of april 30 2018, and as written, it is now possible to require a minimum TLS version directly in Azure for an app service.
I'm having the same issue. I was going to use Cloudflare's WAF to disable TLS 1.0. However, Cloudflare won't sign a BAA, so if you need to be HIPAA compliant, you're hosed. Most people have this issue for PCI compliance, so it shouldn't be an issue.
You can copy your app service into an App Service Environment and disable TLS 1.0 via the cluster settings. However, you have to upgrade to the Premium tier and you have to have at least four servers (2 front end, 2 backend), which is even more expensive. Even with 4 P1s, you're looking at almost a $900 bill ($223/server/month)
You could also set up nginx and have it be a reverse proxy with TLS 1.0 disabled. However, now you have to manage a virtual machine. And since VMs are technically subject to being down, you have to have two nginx boxes in an availability set thrown behind a load balancer. Blech.
Long story short, it just is a really shitty situation. I'm in the same boat and I'm really kind of mad about it.
I wouldn't mind doing the App Service Environment if it wasn't so damn expensive.
I can't find details about what version of TLS is implemented by Secure Gateway.
The documentation is very detailed about how to implement TLS, but I can't find the version used.
https://www.ng.bluemix.net/docs/services/SecureGateway/index-gentopic3.html#sg_007
Where is this information available?
For the application side TLS, Secure Gateway will accept connections from applications that are using TLS 1, 1.1, 1.2. It is up to the app to decide which version of TLS to connect with. If you want to limit what version of TLS is accepted, you can use the REST API to manage the secure options of your destination. This setting is not configurable via the UI.