Disabling versions of the SSL/TLS protocols that support cipher suites which use 3DES as the symmetric encryption cipher in Service Bus

Sanjeev Sirigere 0

Hello,

I got a Critical Vulnerabilities reported against the Service Bus I have provisioned in our Azure subscription with following details. Please note, I have my Service Bus Namespace configured at Minimum TLS version of 1.2 (Service Bus Namespace > Settings > Configuration)

xyz-pre-ncus.servicebus.windows.net

xyz-prod-ncus.servicebus.windows.net

Each of these addresses have been flagged for:

Vulnerability Title: TLS/SSLBirthday attacks on 64-bit block ciphers (SWEET32)

Vulnerability Description:

 Legacy block ciphers having a block size of 64 bits are vulnerable to a practical collision attack when used in CBC mode. All versions of the SSL/TLS protocols that support cipher suites which use 3DES as the symmetric encryption cipher are affected. The security of a block cipher is often reduced to the key size k: the best attack should be the exhaustive search of the key, with complexity 2 to the power of k. However, the block size n is also an important security parameter, defining the amount of data that can be encrypted under the same key. This is particularly important when using common modes of operation: we require block ciphers to be secure with up to 2 to the power of n queries, but most modes of operation (e.g. CBC, CTR, GCM, OCB, etc.) are unsafe with more than 2 to the power of half n blocks of message (the birthday bound). With a modern block cipher with 128-bit blocks such as AES, the birthday bound corresponds to 256 exabytes. However, for a block cipher with 64-bit blocks, the birthday bound corresponds to only 32 GB, which is easily reached in practice. Once a collision between two cipher blocks occurs it is possible to use the collision to extract the plain text data.

Vulnerability Title: TLS Server Supports TLS version 1.0

Vulnerability Description: The PCI (Payment Card Industry) Data Security Standard requires a minimum of TLS v1.1 and recommends TLS v1.2. In addition, FIPS 140-2 standard requires a minimum of TLS v1.1 and recommends TLS v1.2.

Solution provided:

Solution Summary: Disable TLS/SSL support for 3DES cipher suite

Solution: Configure the server to disable support for 3DES suite.For Microsoft IIS web servers, see Microsoft Knowledgebase article (Transport Layer Security (TLS) registry settings ) for instructions on configuring cipher suites. To achieve a higher level of security, one may refer to authoritative sources/guides (Security/Server Side TLS - MozillaWiki ) as well as server vendor documentation to apply an informed cipher configuration.

Solution Summary: Disable insecure TLS/SSL protocol support

Solution: Configure the server to require clients to use TLS version 1.2 using Authenticated Encryption with Associated Data (AEAD) capable ciphers.

Please let me know how I can configure to remove 3DES cipher.

Thanks

Gursimran Singh 570 Reputation points Microsoft External Staff Moderator

2026-08-12T23:58:44.6+00:00

Hi @Sanjeev Sirigere ,

Thank you for sharing the scan results.

Azure Service Bus is a Microsoft-managed service and does not provide a customer-facing option to enable or disable specific TLS cipher suites such as 3DES. Customers can configure the minimum TLS version for the namespace, which you have already set to TLS 1.2. [Use approv...ervice Bus | SharePoint], [learn.microsoft.com]

Reviewing the Nmap output you provided, the endpoint advertises only AES-based TLS 1.2 and TLS 1.3 cipher suites. We do not see any 3DES cipher suite (for example, TLS_RSA_WITH_3DES_EDE_CBC_SHA) in the reported list. Based on this output, the endpoint does not appear to support 3DES. [Disabling...rosoft Q&A | Learn.Microsoft.com]

If a vulnerability scanner is still reporting SWEET32 or TLS 1.0 support, it may be a scanner interpretation issue. Microsoft documentation notes that Service Bus enforces the configured minimum TLS version at the namespace level, and requests using versions lower than the configured minimum are rejected. [Use approv...ervice Bus | SharePoint], [Disabling...rosoft Q&A | Learn.Microsoft.com]

We recommend providing the scanner vendor with the Nmap results and requesting validation of the finding. If you can share the complete scan report, we can review it further and help determine whether the finding is a false positive.

6 answers

Huynh Huu Thang 0 Reputation points

2026-08-07T15:17:55.6266667+00:00
As I understand, your Service Bus is already configured with Minimum TLS Version = 1.2. According to the Microsoft documentation, once this setting is configured, requests using TLS versions lower than the configured minimum should be rejected. Undefined(https://learn.microsoft.com/en-us/azure/service-bus-messaging/transport-layer-security-enforce-minimum-version?WT.mc_id=Portal-fx&source=docs)

Enforce a minimum required version of Transport Layer Security (TLS) for requests to a Service Bus namespace - Azure Service Bus | Microsoft Learn

Since TLS/SSLBirthday attacks on 64-bit block ciphers (SWEET32) are related to the use of the 3DES cipher suite, here is my understanding:

I am not sure whether Azure Service Bus itself still supports 3DES or not, but one possible scenario is that a 3DES cipher suite is still available somewhere in the communication path. If that is the case, a TLS 1.2 connection could still negotiate a 3DES cipher, which may trigger a SWEET32 finding.

For example:

Client (your application) supports:
- TLS 1.0
- TLS 1.1
- TLS 1.2
Cipher Suites:

3DES

AES128-GCM

AES256-GCM

Server supports:

TLS 1.2

TLS 1.3

Cipher Suites:

3DES

AES128-GCM

AES256-GCM

One possible negotiated result could be: TLS 1.2 + 3DES

However, this is only an example to illustrate the concept. To confirm whether this is actually happening, we would need to verify the TLS handshake and the negotiated cipher suite.

I also noticed the vulnerability report mentions Microsoft IIS Web Server recommendations. If you are hosting any related components on Windows Server / IIS, it might be worth checking whether those systems still allow older cipher suites such as 3DES.

You may find these references useful:

How to disable 3DES and RC4 on Windows Server 2019? - Microsoft Q&A Undefined(https://learn.microsoft.com/en-us/answers/questions/348323/how-to-disable-3des-and-rc4-on-windows-server-2019)

TLS Cipher Suites in Windows Server 2022 - Microsoft Learn Undefined(https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-server-2022)

TLS Cipher Suites in Windows 10 v22H2 - Microsoft Learn Undefined(https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v22h2)

In case the finding is a false positive, below are a few tests that may help verify the actual behavior.

Case 1: Force TLS 1.0
```
openssl s_client -connect .servicebus.windows.net:443 -tls1
```
Expected: handshake failure or protocol version not supported

Case 2: Force TLS 1.1
```
openssl s_client -connect .servicebus.windows.net:443 -tls1_1
```
Expected: handshake failure or protocol version not supported

Case 3: Force TLS 1.2
```
openssl s_client -connect .servicebus.windows.net:443 -tls1_2
```
Expected: Success and the TLS handshake details should be displayed.

Please check the negotiated cipher suite in the output:
- If the negotiated cipher is 3DES, then the SWEET32 finding may be valid.
- If the negotiated cipher is AES128-GCM, AES256-GCM, or another modern cipher, then the scanner result may require further investigation.
If possible, it may also be helpful to run:
```
nmap --script ssl-enum-ciphers -p 443 .servicebus.windows.net
```
This should show the supported TLS versions and cipher suites, which can provide stronger evidence than the vulnerability scan report alone.

In any case, if 3DES is still being used anywhere in the environment, I would recommend planning to remove it because it is considered a legacy cipher and is associated with SWEET32.

you might need to read this to remove the 3DES from a Windows Server machine How to disable 3DES and RC4 on Windows Server 2019? - Microsoft Q&A Undefined(https://learn.microsoft.com/en-us/answers/questions/348323/how-to-disable-3des-and-rc4-on-windows-server-2019)

Note: Please verify your applications and dependencies carefully before disabling any cipher suites, just to make sure nothing is still relying on them.

Hope this helps.

Best regards,

A noob guy trying to help people 😄
Was this answer helpful?
Huynh Huu Thang 0 Reputation points

2026-08-07T15:36:13.46+00:00

i did some research and found this Q&A, i think this might help you

https://learn.microsoft.com/en-us/answers/questions/348323/how-to-disable-3des-and-rc4-on-windows-server-2019

Feel free to ask if you need any help.

Sanjeev Sirigere 0 Reputation points

2026-08-08T12:55:29.6233333+00:00

I executed nmap command and I see the below response

nmap --script ssl-enum-ciphers -p 443 ....servicebus.windows.net

Starting Nmap 7.991 ( https://nmap.org ) at 2026-08-08 12:28 +0000

Nmap scan report for ....servicebus.windows.net (20.xxx.xxx.xx)

Host is up (0.017s latency).

PORT STATE SERVICE

443/tcp open https

| ssl-enum-ciphers:

| TLSv1.2:

| ciphers:

| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A

| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A

| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp384r1) - A

| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A

| compressors:

| NULL

| cipher preference: server

| TLSv1.3:

| ciphers:

| TLS_AKE_WITH_AES_256_GCM_SHA384 (secp384r1) - A

| TLS_AKE_WITH_AES_128_GCM_SHA256 (secp256r1) - A

| cipher preference: server

|_ least strength: A

Nmap done: 1 IP address (1 host up) scanned in 4.49 seconds

Does it mean, it does not support 3DES?
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Disabling versions of the SSL/TLS protocols that support cipher suites which use 3DES as the symmetric encryption cipher in Service Bus

6 answers

Case 1: Force TLS 1.0

Case 2: Force TLS 1.1

Case 3: Force TLS 1.2

Your answer