Support for legacy TLS protocols and cipher suites in Azure Offerings

Overview

Microsoft Azure services already operate in TLS 1.2-only mode. There are a limited number of services that still allow TLS 1.0 and 1.1 to support customers with legacy needs. For customers who use services that still support legacy protocol versions and must meet compliance requirements, we have provided instructions on how to ensure legacy protocols and cipher suites are not negotiated. For example, HDInsight provides the minSupportedTlsVersion property as part of the Resource Manager template. This property supports three values: "1.0", "1.1" and "1.2", which correspond to TLS 1.0+, TLS 1.1+ and TLS 1.2+ respectively. Customers can set the allowed minimum version for their HDInsight resource.

This document presents the latest information on TLS protocols and cipher suite support with links to relevant documentation for Azure Offerings. For offerings that still allow legacy protocols to support customers with legacy needs, TLS 1.2 is still preferred. The documentation links explain what needs to be done to ensure TLS 1.2 is preferred in all scenarios.

Documentation Links

FAQ (Frequently Asked Questions)

What is meant by legacy protocols?

Legacy protocols are defined as anything lower than TLS 1.2.

What is meant by legacy cipher suites?

Cipher suites that were considered safe in the past but are no longer strong enough or they PFS. While these ciphers are considered legacy, they are still supported for some backward compatibility customer scenarios.

What is the Microsoft preferred cipher suite order?

For legacy purposes, Windows supports a large list of ciphers by default. For all Microsoft Windows Server versions (2016 and higher), the following ciphers are the preferred set of cipher suites. The preferred set of cipher suites is set by Microsoft's security policy. It should be noted that Microsoft Windows uses the IANA (Internet Assigned Numbers Authority) cipher suite notation. This link shows the IANA to OpenSSL mapping. It should be noted that Microsoft Windows uses the IANA (Internet Assigned Numbers Authority) cipher suite notation. This link shows the IANA to OpenSSL mapping.

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Why is ChaCha20-Poly1305 not included in the list of approved ciphers?

ChaCha20-Poly1305 PolyChacha ciphers are supported by Windows and can be enabled in scenarios where customers control the OS.

Why are CBC ciphers included in the Microsoft preferred cipher suite order?

The default Windows image includes CBC ciphers. However, there are no known vulnerabilities related to the CBC mode cipher suites. We have mitigations for CBC side-channel attacks.

Microsoft’s preferred cipher suite order for Windows includes 128-bit ciphers. Is there an increased risk with using these ciphers?

AES-128 does not introduce any practical risk but different customers may have different preferences with regard to the minimum key lengths they are willing to negotiate. Our preferred order prioritizes AES-256 over AES-128. In addition, customers can adjust the order using the TLS Cmdlets. There is also a group policy option detailed in this article: Prioritizing Schannel Cipher Suites - Win32 apps | Microsoft Docs.

Thanks for reading!

Continue reading...