CRZ-011

Weak TLS (TLSv1.1, 3DES Sweet32, non-PFS ciphers)

medium CVSS 3.1: 3.7 · Asset: vpn.corezoid.com

Summary

TLS cipher audit of vpn.corezoid.com reveals a permissive TLS configuration that is inconsistent with the hardened defaults seen on the other *.corezoid.com hosts:

  1. TLS 1.1 is enabled (TLSv1.1 section appeared in nmap output). TLS 1.0/1.1 were formally deprecated by RFC 8996 in March 2021 and removed from modern browsers (Chrome/Firefox in 2020, Safari in 2020). Any handshake falling back to TLS 1.1 is vulnerable to attacks that don't affect TLS 1.2+.
  2. Three 3DES cipher suites are offered (grade C in nmap ssl-enum-ciphers):
    • TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
    • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
    • TLS_RSA_WITH_3DES_EDE_CBC_SHA 3DES is a 64-bit block cipher — vulnerable to Sweet32 (CVE-2016-2183). In principle, an attacker who can observe a long TLS session (>32 GB of ciphertext with the same key) can recover plaintext via birthday collision. For a VPN login page this is impractical directly, but the presence of these ciphers indicates a legacy TLS profile that a well-placed attacker could downgrade into.
  3. Non-PFS ciphers (TLS_RSA_WITH_*) are offered — these use RSA key exchange rather than ECDHE/DHE, so there is no forward secrecy. If the server's private key is ever compromised (see CRZ-009 for a pattern of key leaks in this org), all past TLS sessions can be retroactively decrypted.
  4. CBC mode ciphers on TLS 1.1 — Lucky Thirteen / BEAST / POODLE-class attacks are mitigated in modern implementations but the cipher family is actively being deprecated.

For comparison, every other *.corezoid.com host tested (admin, account, api, openapi, jira, mw.simulator, sim.simulator) offers only TLS 1.2 and 1.3, only with AEAD (GCM/CHACHA20) ciphers, all grade A. vpn.corezoid.com is the outlier.

The VPN host uses a Sectigo issuer (not AWS ACM like the other hosts) — the cert chain is managed outside the standard ACM flow, which is likely why its cipher suites were never hardened along with the rest of the fleet.

Reproduction

$ nmap -Pn -sT -p 443 --script ssl-enum-ciphers vpn.corezoid.com
[...]
|   TLSv1.1:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A

Evidence

Impact

For a VPN gateway specifically, weak TLS is higher-risk than for typical web hosts because:

  1. VPN sessions are long-lived (hours) — the session duration threshold for Sweet32 is more plausibly reachable than on a web app
  2. VPN traffic contains authentication credentials and session cookies for internal services — compromising it gives access to "trusted" corporate network resources
  3. VPN users are often given more privilege than external users — a compromised VPN session is a direct pivot into internal infrastructure
  4. Downgrade attacks — an attacker who can MITM the TLS handshake may be able to force downgrade to TLS 1.1 + 3DES cipher (if the client also supports it), then attempt Sweet32
  5. No forward secrecy on RSA ciphers means if the Sectigo private key is ever compromised (via a cert store breach, an admin laptop exfil, or a new Sectigo CVE), all past VPN TLS sessions can be decrypted from wire captures

Remediation

Priority 1 — immediate:

  1. Disable TLS 1.0 and 1.1 on the OpenVPN-AS web UI:
    • OpenVPN AS admin console → Server Network Settings → Web Server → TLS protocol settings
    • OR edit /usr/local/openvpn_as/etc/as.conf: cs.https.min_tls_version=1.2
  2. Remove 3DES cipher suites. Configure only AEAD ciphers:
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
    • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  3. Remove non-PFS TLS_RSA_WITH_* ciphers. Force ECDHE/DHE only.
  4. Enable TLS 1.3 if not already — it has only AEAD ciphers and strong defaults.

Priority 2 — systemic:

  1. Extend the TLS hardening that *.corezoid.com ACM-managed hosts already have to the Sectigo-managed hosts
  2. Add a CI check that runs testssl.sh against every new public endpoint before it goes live
  3. Consider consolidating cert management — the fact that vpn.corezoid.com is Sectigo while everything else is ACM suggests cert management sprawl

Verification after remediation

# Should show ONLY TLSv1.2 and TLSv1.3, with only grade-A ciphers
nmap -Pn -sT -p 443 --script ssl-enum-ciphers vpn.corezoid.com

References