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.
Related
I need to listen to Stripe events at a webhook that is deployed on Kubernetes.
The certificate used in the Ingress is using TLS 1.3 but according to Stripe docs, their webhook requests are using TLS 1.2.
Therefore I am getting TLS Errors in the Stripe Webhooks Dashboard.
I am not sure if it is even possible to accept TLS 1.2 requests from a certificate with TLS 1.3 or if I need to add some annotations in the Ingress.
Would greatly appreciate any help.
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.
Our Security team reported use of weak cipher even though we are using TLS 1.2 configuration on our web app. I would like to get clarity about weak cipher suite and how we can remove weak ciphers from our TLS 1.2 configuration as we can see all weak cipher details on the scan site. As Azure functions\web app is a managed service, is there a way to disable them or is it possible to modify registry settings for the application?
For Azure web apps, there is currently no support for removing the cipher suite from a request. It is not possible to make any configuration changes in the Registry settings for web applications as seen in this document - https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#writing-to-registry.
You can only set your TLS settings to 1.2 for high security and a request is negotiated with the client to use whatever cipher they both have, so by default a client will typically use one of the ones that's not weak. There has been feedback from many Azure customers for a feature request to remove/disable insecure ciphers but so far only RC4 has been disabled across the service as seen - https://feedback.azure.com/forums/169385-web-apps-formerly-websites/suggestions/7091994-disable-insecure-ciphers-in-azure-websites?page=2&per_page=20, although Microsoft is constantly reviewing cipher suites.
For now, there are 3 possible ways to remove weak ciphers:
App Service Environment - This gives you access to set your own ciphers though Azure Resource Manager - https://learn.microsoft.com/en-us/azure/app-service/environment/app-service-app-service-environment-custom-settings#change-tls-cipher-suite-order. I reproduced this and found out that it is possible to set your own ciphers or change the cipher suite order by modifying the clusterSettings in https://resources.azure.com/.
Using Azure FrontDoor – You can configure a minimum TLS version in Azure Front Door in the custom domain HTTPS settings via Azure portal. Once you configure TLS1.2, only the following strong cipher suites are supported:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.
You can find more information on this here - https://learn.microsoft.com/en-us/azure/frontdoor/front-door-faq#tls-configuration.
Using Application Gateway – This lets you specify a central TLS policy that's suited to organizational security requirements and helps to meet compliance requirements. The TLS policy includes control of the TLS protocol version as well as the cipher suites and the order in which ciphers are used during a TLS handshake as seen in this document - https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-ssl-policy-overview.
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;