Remediation Guides

SWEET32 Vulnerability Fix: How to Disable 3DES and 64-bit Block Ciphers

26 September 2026 9 min read

SWEET32 (CVE-2016-2183) is a birthday attack on TLS cipher suites that use a 64-bit block cipher, mainly 3DES. Scanners report it as SSL Medium Strength Cipher Suites Supported (SWEET32) or SSL 64-bit Block Size Cipher Suites Supported. Fix it by removing 3DES, DES, IDEA and RC2 from every TLS service, then reboot or reload and rescan.

What the scanner is actually detecting

The scanner handshakes with the service and records every cipher suite the server accepts. If any accepted suite uses a cipher with a 64-bit block size, the finding fires. In practice that is almost always TLS_RSA_WITH_3DES_EDE_CBC_SHA (OpenSSL name DES-CBC3-SHA), but single DES, IDEA and RC2 suites trigger it too.

Scanner ID Finding title
Nessus Plugin 42873 SSL Medium Strength Cipher Suites Supported (SWEET32)
Nessus Plugin 94437 SSL 64-bit Block Size Cipher Suites Supported (SWEET32)
Qualys QID 38657 Birthday attacks against TLS ciphers with 64bit block size vulnerability (Sweet32)

Greenbone/OpenVAS reports the same condition under OID 1.3.6.1.4.1.25623.1.0.108031, and Rapid7 under the check ID ssl-3des-ciphers.

The two Nessus plugins overlap but are not identical. Tenable defines “medium strength” in plugin 42873 as a key length of at least 64 bits and less than 112 bits, or the 3DES suite. Plugin 94437 looks only at block size. Both list CVE-2016-2183, and 94437 also lists CVE-2016-6329 (the OpenVPN variant). Tenable rates both as High (CVSS v3 base score 7.5 for 42873), and a host offering 3DES usually triggers both.

The finding is not limited to port 443. A typical Qualys case, for example in Microsoft’s Q&A forum, is a Windows Server 2016 host flagged on RDP (3389) and SQL Server (1433), because both use the same Windows TLS stack (Schannel) as IIS.

Real-world risk

SWEET32 is real, but it is expensive to pull off. A 64-bit block cipher starts producing block collisions after roughly 232 blocks, and those collisions leak information about repeated plaintext. The researchers’ HTTPS demonstration recovered a cookie after about 30.5 hours and 610 GB of traffic, and they put the typical requirement at around 785 GB. The attack needs all of the following:

  • A network position where the attacker can capture the victim’s traffic.
  • A single long-lived connection that actually negotiated a 64-bit cipher.
  • A secret (such as a session cookie) that is sent again and again, typically forced by attacker JavaScript running in the victim’s browser.

That is a confidentiality issue for one secret, not remote code execution. Against RDP or SQL Server traffic, arranging for a secret to be repeated billions of times over one connection is much harder than in a browser. In short: low practical risk, a trivial fix, and a High rating on every scan until the cipher is gone.

How to confirm it on the host

From any Linux or macOS machine with Nmap, enumerate what the service accepts. The ssl-enum-ciphers script prints a warning line that names SWEET32 when 3DES is offered, and it also works on RDP:

nmap -sV --script ssl-enum-ciphers -p 443,3389 host.example.com

Look for 64-bit block cipher 3DES vulnerable to SWEET32 attack in the output. To test a single cipher directly with OpenSSL:

openssl s_client -connect host.example.com:443 -tls1_2 -cipher '3DES:@SECLEVEL=0' </dev/null

A completed handshake means the server accepts 3DES. A no cipher match error means your local OpenSSL build has no 3DES suites at all, so rely on Nmap instead.

On a Windows server, list the enabled suites locally. The -Name match is a case-sensitive substring, so DES catches both 3DES and single DES suites:

Get-TlsCipherSuite -Name DES | Format-Table Name

Then check whether Group Policy already controls the list, because that changes which fix will stick:

Get-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftCryptographyConfigurationSSL0010002' -Name Functions -ErrorAction SilentlyContinue

How to fix it

Windows Server (IIS, RDP, SQL Server and other Schannel services)

One Schannel change covers IIS, RDP on 3389, SQL Server on 1433 and anything else that uses the Windows TLS stack. Microsoft’s cipher suite tables show TLS_RSA_WITH_3DES_EDE_CBC_SHA enabled by default on Windows 10 version 1809 (the Windows Server 2019 code base) and Windows Server 2022, and note that it is no longer enabled by default from Windows Server 2022 23H2 onward. If you are working through a wider baseline, this belongs on your Windows Server hardening checklist.

Option 1: TLS PowerShell cmdlets. Remove every DES-family suite from the local list:

Get-TlsCipherSuite -Name DES | ForEach-Object { Disable-TlsCipherSuite -Name $_.Name }

For the single suite that scanners usually name, Microsoft’s own example is:

Disable-TlsCipherSuite -Name 'TLS_RSA_WITH_3DES_EDE_CBC_SHA'

Microsoft notes that these cmdlets cannot change the list if it is already set through Group Policy or if the Functions value exists under the policies key shown above. In that case, use option 3.

Option 2: disable the ciphers in the Schannel registry. Microsoft’s Exchange Server TLS guidance disables outdated ciphers under HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers by setting Enabled to 0. This blocks the cipher even if a suite is re-added later. Key names such as DES 56/56 contain a forward slash, which is why Microsoft creates them with the .NET CreateSubKey call:

$base = "SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers"
New-Item -Path "HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL" -Name "Ciphers" -ErrorAction SilentlyContinue
foreach ($c in "Triple DES 168", "DES 56/56", "RC2 40/128", "RC2 56/128", "RC2 56/56") {
    (Get-Item HKLM:).OpenSubKey($base, $true).CreateSubKey($c) | Out-Null
    Set-ItemProperty -Path "HKLM:$base$c" -Name "Enabled" -Value 0 -Type DWord
}

Schannel has no IDEA cipher suites, so there is nothing to disable for it. Microsoft’s general TLS registry reference now says ciphers should be controlled through cipher suite order, so treat this as an extra layer on top of option 1 or 3, not a replacement.

Option 3: Group Policy. For domain-wide rollout, open Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order, set it to Enabled, and paste a comma-separated list that contains no 3DES or DES suite. The list is limited to 1,023 characters. Keep ECDHE with AES-GCM suites at the top: Microsoft warns that HTTP/2 web services fail with non-HTTP/2-compatible suites.

Option 4: IIS Crypto. Nartac’s IIS Crypto applies a whole template and its command line version can back up the current registry first:

iiscryptocli /backup before-sweet32.reg /template best

The Best Practices template also disables TLS 1.0 and 1.1, which is a larger change than SWEET32 needs. Review it in the GUI first and confirm Triple DES 168 is unticked.

Whichever option you use, reboot. Microsoft states that cipher suite order changes take effect on the next boot, and services such as RDP and SQL Server reuse their TLS credential handles until they restart.

Apache httpd and nginx

Both read an OpenSSL cipher string. The ! prefix deletes a cipher permanently, so it cannot be re-added later in the same string. For Apache (mod_ssl):

SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!DES:!IDEA:!RC2
SSLHonorCipherOrder on

For nginx, whose default is HIGH:!aNULL:!MD5:

ssl_ciphers HIGH:!aNULL:!MD5:!3DES:!DES:!IDEA:!RC2;

Do not assume HIGH alone excludes 3DES. Check what your build resolves the string to before deploying; no line should show 3DES or DES:

openssl ciphers -v 'HIGH:!aNULL:!MD5:!3DES:!DES:!IDEA:!RC2'

Then run apachectl configtest or nginx -t and reload. Check every virtual host and included file: one vhost with its own SSLCipherSuite line keeps the finding alive on its port.

Java services

Java controls this through the jdk.tls.disabledAlgorithms security property in $JAVA_HOME/conf/security/java.security (jre/lib/security/java.security on Java 8). Current OpenJDK releases already include DES and 3DES_EDE_CBC in the default value, so a Java service flagged for SWEET32 usually runs an old bundled runtime or has an edited list. Update the runtime, or add the entries back:

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, 3DES_EDE_CBC, ...

Keep the rest of your existing value intact, then restart the service.

Appliances and load balancers

If TLS terminates on a load balancer, reverse proxy or appliance, remove 3DES from its cipher profile there, following the vendor’s documentation. The backend server’s settings never reach the client.

How to verify the fix and rescan

  1. After the reboot, run Get-TlsCipherSuite -Name DES on Windows hosts. It should return nothing.
  2. Rerun nmap --script ssl-enum-ciphers against every affected port, including 3389 and 1433 where applicable, and confirm no 3DES suite or SWEET32 warning remains.
  3. Run a targeted rescan with the same policy and credentials that raised the finding. Plugins 42873 and 94437, QID 38657, or the OpenVAS and Rapid7 equivalents should be gone for that host and port.

What can break and how to roll back

  • Very old clients. Windows XP era systems, embedded devices and legacy Java runtimes may have no AES suite in common with your server. Their handshakes fail after the change. Check your web or connection logs for them before the maintenance window.
  • Template side effects. IIS Crypto’s Best Practices template also turns off TLS 1.0 and 1.1, which breaks more clients than removing 3DES does.
  • Truncated GPO list. A cipher list over 1,023 characters, or one missing its commas, can leave the server with fewer suites than you intended.
  • Rollback on Windows: re-enable the suite at the bottom of the list with Enable-TlsCipherSuite -Name TLS_RSA_WITH_3DES_EDE_CBC_SHA -Position 4294967295, remove the Enabled values you created under SCHANNELCiphers, set the GPO back to Not Configured, or import the IIS Crypto backup file. Then reboot.
  • Rollback on Apache, nginx and Java: restore the previous config file and reload or restart the service.

Common false positive reasons

  • No reboot yet. The registry or GPO is correct, but Schannel still uses the old list until the next boot.
  • Group Policy wins. A domain GPO with its own cipher list silently overrides local cmdlet changes at the next policy refresh.
  • A different port. Port 443 is clean, but RDP, SQL Server, a management interface or a second vhost still offers 3DES. The plugin output names the exact port and suite.
  • Something in front of the host. The scanner is talking to a load balancer or TLS-inspecting proxy, not the server you fixed.
  • Other medium-strength ciphers. Plugin 42873 also covers ciphers with keys shorter than 112 bits, so read its output if it remains after 3DES is gone.

FAQ

Is SWEET32 still exploitable today?

Technically yes, wherever 3DES is negotiated, but it requires hundreds of gigabytes of captured traffic over a single connection. It is low risk, yet easy to fix, so there is little reason to accept it.

Will disabling 3DES break RDP?

Not for current Windows RDP clients, which negotiate AES. Only very old clients that support nothing stronger are affected. For the rest of port 3389, see our RDP hardening guide.

Is there a patch for CVE-2016-2183?

The fix is configuration: stop offering 64-bit block ciphers. Newer Windows Server releases simply do not enable the 3DES suite by default.

Why does Nessus still report plugin 42873 after I disabled 3DES?

Usually a pending reboot, a GPO overriding the local change, or another port on the same host. Check the plugin output for the port and suite name.

Tracking this finding across many hosts

SWEET32 tends to appear on dozens of servers at once, often under several scanner IDs. SITEY is a self-hosted vulnerability management platform that imports findings from 16 scanners; it merges duplicates per scanner, not across scanners, so a Nessus 42873 and a Qualys QID 38657 on the same host stay separate entries. Its AI can write host-specific remediation scripts that its agents deploy on Windows and Linux endpoints only after human approval, and per-finding retest is available for Nessus, Acunetix and Burp findings.

Sources

SITEY closes the loop, not just the report.Discover, validate, fix and verify in your own infrastructure.

See pricing
← All articles