Encryption Downgrade Protection Not Responding Correctly

Vulnerability Explanation

The testssl scanner probes the server by sending a ClientHello with the TLS_FALLBACK_SCSV pseudo-cipher suite (0x56,0x00) at a deliberately downgraded TLS version. Per RFC 7507, a correctly configured server that supports a higher TLS version than the one advertised in the ClientHello MUST respond with a fatal 'inappropriate_fallback' alert (alert number 86). Instead, this server returned a generic 'handshake_failure' alert. This indicates the server either does not recognise the SCSV signal at all (outdated OpenSSL/TLS library), or has a TLS version configuration gap that causes it to mishandle the signal. The net effect is that the downgrade-detection mechanism is not operating as the RFC requires.

Root Cause

The root cause is most likely one of two conditions: (1) the underlying TLS library (OpenSSL or equivalent) is too old to support TLS_FALLBACK_SCSV — support was added in OpenSSL 1.0.1j, 1.0.0o, and 0.9.8zc; or (2) the server's enabled TLS protocol range has a 'version gap' (e.g., TLS 1.1 disabled but TLS 1.0 and 1.2 both enabled), causing the SCSV logic to misfire and emit a generic handshake failure rather than the correct inappropriate_fallback alert.

Technical Impact

Without a correctly functioning TLS_FALLBACK_SCSV implementation, a network-positioned attacker can attempt a protocol downgrade attack — interfering with the initial TLS handshake to force the client to retry at a lower protocol version. If the server also supports weak protocol versions (TLS 1.0, SSL 3.0), this could expose the connection to known attacks such as POODLE. On servers that only support TLS 1.2+, the practical risk is low, but the misconfigured response still indicates a non-compliant TLS stack.

Severity Justification

Exploitability requires a network-level man-in-the-middle position, making opportunistic exploitation unlikely. Risk is substantially reduced if weak protocol versions (TLS 1.0, SSL 3.0) are already disabled. The finding is primarily a defence-in-depth control gap and a compliance concern rather than an immediately exploitable vulnerability.

Affected Components

• OpenSSL < 1.0.1j (1.0.1 branch)
• OpenSSL < 1.0.0o (1.0.0 branch)
• OpenSSL < 0.9.8zc (0.9.8 branch)
• Any TLS stack lacking RFC 7507 support

Remediation Steps

1. Update OpenSSL to a supported release (3.x recommended; 1.1.1 minimum). TLS_FALLBACK_SCSV support is automatic once the library is updated — no explicit configuration directive is needed for Nginx or Apache when using a modern OpenSSL.
2. Restrict the server to TLS 1.2 and TLS 1.3 only, eliminating any version gaps that can confuse SCSV handling. For Nginx: ssl_protocols TLSv1.2 TLSv1.3; — For Apache: SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
3. Reload or restart the web server after making configuration changes.
4. Re-run testssl to confirm the server now returns 'inappropriate_fallback' (alert 86) rather than 'handshake_failure' when probed with TLS_FALLBACK_SCSV.

Verification Steps

1. Run: openssl version — confirm the output shows OpenSSL 1.1.1 or 3.x.
2. Run testssl against the host and check the TLS_FALLBACK_SCSV line — a passing result reads 'Downgrade attack prevention supported (OK)'.
3. Manually verify with: openssl s_client -connect <host>:443 -fallback_scsv -tls1_2 — a correctly configured server supporting TLS 1.3 will respond with 'tlsv1 alert inappropriate fallback' (alert 86).

Code Examples (nginx)

# Nginx — outdated protocol range with version gap (triggers wrong alert)
ssl_protocols TLSv1 TLSv1.2 TLSv1.3;  # TLS 1.1 missing creates a gap

# Nginx — correct: TLS 1.2 and 1.3 only, no gaps
ssl_protocols TLSv1.2 TLSv1.3;

# Apache — equivalent
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

Best Practices

• Disable all protocol versions below TLS 1.2 — this is the most effective defence against downgrade attacks and makes SCSV a complementary rather than primary control.
• Keep the underlying TLS library (OpenSSL/LibreSSL) on a supported release; SCSV support and correct behaviour depend entirely on the library version.
• Avoid non-contiguous TLS protocol ranges (e.g., enabling 1.0 and 1.2 but not 1.1) as these can cause unexpected SCSV behaviour.
• Use automated TLS configuration scanners (testssl, SSL Labs) as part of your regular deployment pipeline to catch regressions early.

References

• datatracker.ietf.org/doc/rfc7507/
• www.openssl.org/news/secadv/20141015.txt
• docs.veracode.com/r/enable-tls_fallback_scsv
• www.virtuesecurity.com/kb/tls_fallback_scsv-not-supported/