Skip to main content

Encryption finding · Edge

SWEET32 / 3DES Cipher Suites Enabled: Fix It or Document It

Your scanner flagged SWEET32 or 3DES cipher suites. What the finding means, how to remove 3DES, and how to document it when a legacy system can't change.

What the scanner said

SWEET323DES cipher suites supportedMedium strength cipher suites supported

Your server still offers Triple DES (3DES) cipher suites, such as TLS_RSA_WITH_3DES_EDE_CBC_SHA. 3DES encrypts in 64-bit blocks, and an attacker who captures about 32 GB of traffic inside one long-lived connection can start recovering pieces of plaintext, such as a session cookie. The attack is called SWEET32 (CVE-2016-2183).

Why it matters

Scanners flag this finding at NVD 7.5 (CVSS v3.1) and 5.0 (v2), and NIST no longer approves Triple DES for new encryption (SP 800-131A Rev. 2, disallowed after 2023). A cipher list that offers it conflicts with NIST guidance, so a NIST 800-53 assessment, a NERC CIP audit, or a customer security review will ask about it. The attack itself is hard to run against ordinary traffic.

A PCI ASV scan also fails on it, because an ASV fails any score of 4.0 or higher.

The fix

Remove 3DES from every listener that terminates TLS: web servers, load balancers, CDNs, mail servers, and VPN gateways.

# nginx
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

# Apache (mod_ssl)
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384

# Other OpenSSL-based services (HAProxy, Postfix, Dovecot): exclude 3DES from the cipher string, then restart
CipherString = DEFAULT:!3DES

# Windows Server 2008 R2 through 2022 (IIS, RDP, other Schannel services), then reboot
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168" /v Enabled /t REG_DWORD /d 0 /f

On Windows Server, including 2016, 2019, and 2022, you can instead remove the 3DES suites from the SSL Cipher Suite Order group policy. On Linux, run openssl ciphers -v 'DEFAULT:!3DES' to confirm the string leaves no 3DES suite.

On a managed load balancer or CDN, choose a TLS 1.2 or later security policy that excludes 3DES. Check your client inventory first, because some older Windows clients negotiate nothing else.

Verify. Run the check below against each listener.

nmap -sT -Pn --script ssl-enum-ciphers -p 443 <host>

A fixed host lists no 3DES suite and ends with least strength: A. A vulnerable host lists the 3DES suite graded C with a SWEET32 warning. Rerun your scanner as well, and keep the before and after output as the evidence that the finding is closed.

When you can't fix it

Some assets offer only 3DES: industrial gateways, appliances past vendor support, and older payment terminals. Your named owner chooses one treatment.

  • Remediate by replacing or upgrading the asset, with a dated plan.
  • Mitigate by terminating TLS in front of it with a proxy that speaks modern TLS to clients and reaches the asset over a segmented internal hop. Keep it off the internet, restrict it to an allowlist of client addresses, and cap requests per connection so no single key encrypts anywhere near 32 GB.
  • Accept with documented compensating controls: the asset, why it can't change, the controls above, the owner, a review date, and a replacement date. For a PCI ASV scan, submit that record through the ASV's dispute process. The ASV reviews the evidence and decides.

The post Compensating Controls for Legacy Systems covers which controls carry weight and how to write the record an assessor accepts.

Where it lands in the Risk Register

FindingTreatmentOwnerEvidence
SWEET32 / 3DES suites on a named listenerRemediate, mitigate, or accept (the owner decides)Named by youBefore and after scan output. Maps to NIST 800-53 SC-8 and SC-13, and PCI DSS 4.2.1.

Common questions

Can SWEET32 be exploited in practice?

It needs an attacker on the network path, about 32 GB of captured traffic under one key, and some known plaintext, so it is hard to run against ordinary short-lived connections. Long-lived connections are the exposure. The finding stays on scan reports because the score and NIST's position on 3DES do not depend on how hard the attack is.

Will disabling 3DES break anything?

Only clients that support nothing else, such as Windows Server 2008 R2 over RDP and some older embedded devices. Check your client inventory, or watch the server's handshake logs, before you change the listener.

Can I pass a PCI scan with 3DES still enabled?

Only through the ASV's dispute process, with a compensating-control record. The ASV reviews the evidence and decides, so removing 3DES is the reliable route.

Need the finding closed, or documented so it stays open with your assessor's acceptance?