Please let us choose what Cipher to use and Disable/Enable TLS versions in Azure Web Apps.
This is supported via App Service Environment (ASE):
Has anybody had luck with Leow Kah Man's solution in the comment from July 4 2017?
Leow Kah Man commented
I managed to get around using Application Gateway, without ASE.
You need to be able to setup subdomain CNAME though.
Solution described here:
Happy to hear postiive/negative feedback from anyone.
This is not an acceptable solution for most people looking for this feature. In my opinion, implementing only for ASE should not warrant this being marked as completed. This is obviously still an open concern for users of multi-tenant PaaS.
Drew Marsh commented
Surprised and disappointed to find that this is still not possible to control at the "pure"-PaaS Azure Web Apps level.
I agree with all others that have commented here. The cost to jump to an ASE environment is prohibitive for small companies. An option to disable this should be provided across all levels of Web Apps.
Owen - Acumy commented
In order to allow web apps as an option where security scans are required, the community needs a way to choose the level of TLS and cipher support. I understand that this is not easy, as SSL/TLS terminates upstream in the infrastructure, but surely there could be pools of web app infrastructure available with, say, varying levels of extremely tight to relatively loose TLS restriction, under which your web app is installed on demand (even a required delay of a few hours for a deployment change would be acceptable.)
syed arish commented
ASE is very expensive way of disabling a minor security issue.
You cannot expect us to incur the high cost of an App Service Environment just to get to a platform that complies with modern security standards
This is absurd. You cannot expect us to incur the high cost of an App Service Environment just to get to a platform that complies with modern security standards.
Any basic scan of an Azure Web App shows that TLS 1.0, an insecure transportation security protocol, is supported. This vulnerability is unacceptable. You need to provide an option to disable it.
This is basic security. Fix this or we're switching cloud provider.
Charles Nasoon commented
any news on this or should I migrate to Amazon ?
Colin Mierowsky commented
Any update on this?
According to https://feedback.azure.com/forums/169385-web-apps-formerly-websites/suggestions/13097865-either-sun-set-tls-1-0-or-give-users-the-means-to this request has been declined.
Bart Verkoeijen commented
With SWEET32 https://sweet32.info/ and CVE-2016-2183, CVE-2016-6329, prompt action should be taken to remove this cipher asap and disable 3-DES on the server.
Remove the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher. This is no longer PCI 3.1 compliant.
Still an issue, any plans to provide a solution?
We are on the brink of switching to AWS simply because this is a complete block for us. Switching to an ASE is out of the question due to the high and unnecessary expense.
To add to the chorus... "Disabling TLS 1.0 is supported in ASE" is not the answer to this suggestion due to the significant increase in cost. You literally jump from from $149/mo for two S1 instances to $1475/mo for the lowest-cost ASE configuration.
Ryan Salter commented
PCI compliance is the underlying issue and TLS 1.0 needs to be disabled. The ideal solution is that Azure websites have an option to be PCI compliant, or PCI 3.1 compliant. I'm having an issue with compliance on Azure hosted websites and will be forced to move them to another host. The fact that deadline is delayed until 2018 does not equate to compliance in the meantime. I have an immediate need to be fully compliant.
P Pelzer commented
+1.... We have many clients who need to be compliant. Microsoft praises itself for its security but this easy to score item is left hanging.