Blog Post

Apps on Azure Blog
2 MIN READ

FAQ on App Service cipher suites

Leo_Yang's avatar
Leo_Yang
Former Employee
Jul 26, 2023

Q1: What are cipher suites and how do they work on App Service?

 

Q2: How to confirm the supported cipher suites on App Service server side?

 

Q3: Why does App Service support some weak cipher suites?

  • For the purpose of backward compatibility when someone is using a legacy browser, which usually requires weak cipher suites to establish an SSL connection. Otherwise, the client will meet SSL errors.

 

Q4: What has Azure App Service done to make it as secure as possible?

  • Azure Web App places the strongest and most secure cipher suites in the front of our cipher order.
  • The cipher suite order is in line with guidance from Azure Security.

 

Q5: How to disable some of the weak cipher suites?

Published Jul 26, 2023
Version 1.0

1 Comment

  • fhurta's avatar
    fhurta
    Copper Contributor

    I'm confused by different results coming from SSL Labs scan and running Get-TlsCipherSuite in AppService's Kudu. Specifically, cipher suite at first position shown by Powershell command, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, is not listed in SSL Labs report at all - SSL Labs shows only TLS_ECDHE_RSA_* but no TLS_ECDHE_ECDSA_*.

     

    I'm trying to connect from the AppService to another service using SslStream and getting error in SSL Handshake. On the party I'm trying to connect to there is a log entry: SSL routines:tls_post_process_client_hello:no shared cipher.

    The other party confirms they support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (in fact they support multiple TLS_ECDHE_ECDSA_* but no TLS_ECDHE_RSA_*).

     

    Supposing SSL Labs is correct then I would understand there is no shared cipher. But Get-TlsCipherSuite still shows the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 at first position..  

    So which one is correct?