Long-term commitment to supporting protocols and protocol versions is a key expectation customers have from commercial cloud services. Deployed solutions, and especially widely deployed client applications that are often operated outside the original developer’s control, are expected to not become spontaneously broken and cut off from cloud services by protocols being retired. 

When it comes to long-term support, security protocols such as Transport Layer Security (TLS, colloquially also still referred to as SSL) are the toughest to manage, because information security professionals rightfully push to expediently upgrade to the latest versions at the earliest time – with information security policies reflecting this – while there are significant client deployments “out there” which cannot be easily upgraded to that latest version, often also due to platform limitations. “Just change the code to the latest runtime and recompile” is often not a practical option for a variety of reasons. 

Azure Service Bus is one of the oldest services in Azure, with some of its existing protocol surface area in active use by customers dating back to even before commercial availability in 2010, and there are quite a few applications that have been built and deployed years ago using TLS 1.0 and are considered by ISVs and/or their customers to “just work”, even if we here at Microsoft disagree from a security policy perspective. TLS 1.0 is problematic, but for some customers or their clients not problematic enough to rush to retire all uses of it in older systems. That’s why we still offer TLS 1.0 and TLS 1.1 as an endpoint option. 

That all said: If application deployments under your control or watch are still relying on TLS 1.0 or TLS 1.1, those are on borrowed time. The clock is ticking loudly and many customers who are known to have such dependencies have already received or will receive communication from Azure to that effect; the Azure platform will retire TLS 1.0 and TLS 1.1 as a matter of global policy all at the same time for services that still support it. 

Even while TLS 1.0 and TLS 1.1 remain an option on the Service Bus gateways, your own applications can ensure to be in full compliance with current policies and always use TLS 1.2. The TLS protocol version and the TLS cipher suites are ultimately always a client choice to make, and the client can always refuse to communicate further if the offered capabilities are outside of its desired compliance framework.  

Enforcing use of TLS 1.2 with in-support clients 

If your Service Bus clients are up to date, you are generally using TLS 1.2. 

If you are using any version of the official .NET Standard client (Microsoft.Azure.ServiceBus on Nuget) or version 3.4.3 or later of the .NET Framework client (WindowsAzure.ServiceBus on Nuget) and you are using the .Net Framework 4.7.1 or newer, your application will automatically follow the .NET Framework guidance model for TLS and always follow the OS configuration settings and respective .NET Framework overrides. Current versions of Windows default to using TLS 1.2. 

For .NET Framework 4.6, you will have to enforce the use of TLS 1.2 in the startup of your application by setting  

        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 

or by enforcing the use of HTTPS tunnelling (see further below). 

If you are using the official Java client (azure-servicebus on Maven), the client will automatically follow the Java platform rules for enforcing TLS 1.2, where TLS 1.2 is the default. 

If you are using a custom AMQP 1.0 client, refer to the respective project documentation for how to enforce TLS 1.2 use. The Microsoft lower-level AMQP libraries for .NET (Microsoft.Azure.Amqp and AmqpNetLite) follow the .NET Framework guidance and default to TLS 1.2. The Apache Qpid Proton AMQP libraries generally default to TLS 1.2 today. 

Enforcing use of TLS 1.2 with out-of-support clients 

The only scenarios where enforcing use of TLS 1.2 is substantially trickier involve using out-of-date clients where it’s impossible to follow the .NET Framework guidance to upgrade to .NET 4.7.2. 

If you are using the .NET Framework client (WindowsAzure.ServiceBus on Nuget) with version 4.5.x of the .NET Framework and you are using the AMQP transport, you must use version 3.4.3 of that client or later to enforce the use of TLS 1.2. 

If you are instead using the (default) NetMessaging transport, which is based on WCF, the .NET Framework versions 4.5.x and earlier have TLS version 1.0 hardcoded for the native WCF transport option, but for Service Bus you can circumvent this when you enforce HTTPS tunnelling, which follows the operating system default rules.  

If you don’t have source code access or can’t change your deployment, and the client does not explicitly override the ServiceBusEnvironment.SystemConnectivity.Mode setting to ConnectivityMode.Tcp, you can simply enforce HTTPS tunnel usage by suppressing outbound connectivity on ports 9350-9354 with a local firewall.  

You can enforce HTTPS usage by setting 

        ServiceBusEnvironment.SystemConnectivity.Mode=ConnectivityMode.Https 

Supported Cipher Suites 

A key concern with older implementations of TLS is that they prefer outdated cipher suites. The Service Bus TLS configuration only offers the following options, in order of service-side preference.  

The last three options are only temporarily retained for compatibility with some of the oldest clients. 

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030), ECDH x25519 (eq. 3072 bits RSA) 
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f), ECDH x25519 (eq. 3072 bits RSA) 
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028), ECDH x25519 (eq. 3072 bits RSA) 
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027), ECDH x25519 (eq. 3072 bits RSA) 
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014), ECDH x25519 (eq. 3072 bits RSA) 

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013), ECDH x25519 (eq. 3072 bits RSA) 
• TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 
• TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 
• TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 
• TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 

• TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 
• TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 
• TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 

Summary 

Please verify that your applications are configured to use TLS 1.2. If they do, and this is purely a client choice, your applications will be in compliance with all policies that require TLS 1.2.  

While TLS 1.0 and TLS 1.1 is still an endpoint option on Service Bus, you should consider it urgent to move existing applications using out-of-support clients to TLS 1.2, because its foreseeable that these versions will be retired from use across all Azure cloud services.