SSL Medium Strength Cipher Suites Supported

This finding means a TLS service still negotiates 3DES or another 64-bit block cipher, which maps to SWEET32 / CVE-2016-2183. The weakness is not tied to one neat product range; it affects any server or client stack that still permits those legacy ciphers, and scanners usually flag suites like DES-CBC3-SHA. In OpenSSL, mitigation landed in 1.0.2i / 1.0.1u, and 1.1.0 disabled those DES-based suites by default.

The vendor baseline overstates operational risk. CVSS treats this like a simple network-reachable confidentiality bug, but the real exploit path usually needs attacker-in-the-middle visibility or browser foothold, an actual 3DES-negotiated session, a long-lived connection, repeated secret-bearing traffic, and massive data volume. That makes it a legitimate hardening issue and compliance blemish, but usually not an urgent enterprise patch-priority event.

Why this verdict

• Start from 7.5, then cut hard for attacker position: practical exploitation normally needs MitM visibility or equivalent browser foothold, which implies a prior compromise stage or privileged network position that CVSS does not capture.
• Cut again because server support is not exploitability: Nessus proves the endpoint *offers* 3DES, but a real victim must also *negotiate* it. In modern estates, many clients prefer AES/TLS 1.2+ or TLS 1.3, which narrows reachable population sharply.
• Cut again for data-volume and session-lifetime requirements: the published HTTPS demo needed enormous traffic and a long-lived session with repeated secrets. That is real cryptographic weakness, but poor attacker ROI compared with phishing, token theft, or edge RCE.

Why not higher?

This is not a one-packet unauthenticated break. It does not hand over code execution, domain takeover, or trivial remote shell access, and the exploit chain depends on several compounding prerequisites that modern deployments often break naturally. That makes a HIGH or CRITICAL call inappropriate for most 10,000-host environments.

Why not lower?

It is still a real confidentiality weakness, not scanner theater. If you still expose legacy 3DES on internet-facing portals, old VPNs, or brittle embedded platforms, a determined attacker with the right position can exploit it. It also remains valid crypto-baseline debt and will keep tripping audits and external assessments.

1. Disable 3DES and other 64-bit block ciphers — Remove 3DES / DES-CBC3-SHA and equivalent suites from server-side cipher policy wherever the platform allows it. For a LOW noisgate verdict there is no mitigation SLA; treat this as backlog hygiene and complete it in the next normal TLS-hardening change window.
2. Triage internet-facing and VPN endpoints first — If you cannot clean up everything at once, start with externally reachable web apps, load balancers, reverse proxies, and remote-access concentrators where victim traffic volume and attacker reachability are most plausible. For LOW, there is no special emergency deadline; fold it into routine exposure reduction work.
3. Validate actual negotiation, not just library version — Re-test endpoints with handshake enumeration after each change because many products bundle their own TLS stack and ignore OS-level cipher settings. This matters more than package version alone because SWEET32 is fundamentally a negotiated-cipher problem.

Run this from an auditor workstation or jump host that can reach the target TLS service: ./check_sweet32.sh app.example.com 443. It needs no administrative privileges; nmap is preferred for accuracy, and the script falls back to openssl if nmap is unavailable.

#!/usr/bin/env bash
# check_sweet32.sh
# Detect whether a remote TLS service still negotiates 3DES / SWEET32-prone ciphers.
# Usage: ./check_sweet32.sh <host> [port]
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage error

set -u

HOST="${1:-}"
PORT="${2:-443}"

if [ -z "$HOST" ]; then
  echo "UNKNOWN: usage: $0 <host> [port]"
  exit 3
fi

# Prefer nmap because it enumerates server-accepted suites reliably.
if command -v nmap >/dev/null 2>&1; then
  OUT="$(nmap -Pn --script ssl-enum-ciphers -p "$PORT" "$HOST" 2>/dev/null)"
  if [ -z "$OUT" ]; then
    echo "UNKNOWN: no output from nmap"
    exit 2
  fi

  if echo "$OUT" | grep -Eiq '3des|des-cbc3|des-cbc'; then
    echo "VULNERABLE"
    exit 1
  fi

  if echo "$OUT" | grep -Eiq 'ssl-enum-ciphers|TLSv1\.[0-3]|ciphers'; then
    echo "PATCHED"
    exit 0
  fi

  echo "UNKNOWN: unable to interpret nmap output"
  exit 2
fi

# Fallback to openssl s_client. This is less reliable on systems where legacy ciphers are unavailable.
if command -v openssl >/dev/null 2>&1; then
  OUT="$(printf '' | openssl s_client -connect "${HOST}:${PORT}" -servername "$HOST" -tls1_2 -cipher 'DES-CBC3-SHA:@SECLEVEL=0' 2>/dev/null)"

  if echo "$OUT" | grep -Eq 'Cipher is DES-CBC3-SHA|Cipher *: *DES-CBC3-SHA|New, .*DES-CBC3-SHA'; then
    echo "VULNERABLE"
    exit 1
  fi

  if echo "$OUT" | grep -Eq 'handshake failure|no cipher match|alert handshake failure|ssl handshake has read'; then
    echo "PATCHED"
    exit 0
  fi

  echo "UNKNOWN: openssl could not confirm whether 3DES is accepted"
  exit 2
fi

echo "UNKNOWN: neither nmap nor openssl is installed"
exit 2

Sources

1. Tenable Nessus Plugin 42873
2. NVD CVE-2016-2183
3. OpenSSL blog: The SWEET32 issue
4. SWEET32 research site
5. OpenSSL Security Advisory 2016-09-22
6. CISA Known Exploited Vulnerabilities Catalog
7. CVE Details EPSS snapshot for CVE-2016-2183
8. Original CCS paper PDF