First published on on Nov 22, 2018
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
on Nuget) or version 3.4.3 or later of the
.NET Framework client
(WindowsAzure.ServiceBus on Nuget)
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.
.NET Framework 4.6
, you will have to enforce the use of TLS 1.2 in the startup of your application by setting
or by enforcing the use of HTTPS tunnelling (see further below).
If you are using the official
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 (
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
If you are using the
.NET Framework client
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
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.
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.