Disabling TLS Renegotiation in Production

June 5, 2026 | 9 min read | TLS Security

TLS renegotiation allows a client to initiate a new handshake within an established TLS session. The original purpose was to allow servers to request client certificates mid-session without closing the connection. In practice, this feature is almost never used by legitimate applications, but it is exploited by attackers as a CPU amplification vector: a single established TCP connection can trigger dozens of server-side TLS re-handshakes at a fraction of the bandwidth cost of initiating new connections. The CVE-2009-3555 vulnerability formalized this attack path, and while RFC 5746 added renegotiation indication, the feature itself remains a resource exhaustion risk and should be disabled in production servers.

TLS 1.3 eliminates renegotiation entirely -- it is not supported in the protocol. Organizations that have fully migrated to TLS 1.3 are not exposed to this attack via TLS 1.3 connections. However, DDactic regularly finds servers that still support TLS 1.2 for backward compatibility, which means renegotiation support persists unless explicitly disabled.

Verification First

Before disabling renegotiation, verify whether any production clients depend on it. Client certificate authentication over TLS 1.2 with server-initiated renegotiation is the only legitimate production use case. Check your application logs and TLS session statistics for renegotiation events before making the change. In most web application stacks, the count will be zero or negligible, confirming that disabling the feature carries no compatibility risk.

# Check if renegotiation is supported on your server:
openssl s_client -connect example.com:443 -tls1_2 << EOF
R
EOF
# If the server supports renegotiation, you will see:
# RENEGOTIATING
# If renegotiation is disabled, you will see an error or connection close

Nginx Configuration

# nginx.conf — disable SSL renegotiation
# Nginx does not have a direct renegotiation disable directive,
# but setting ssl_protocols to TLSv1.3 only eliminates the attack surface:
ssl_protocols TLSv1.3;

# If TLS 1.2 must be supported for client compatibility,
# use the SSL_OP_NO_RENEGOTIATION option via ssl_conf_command (Nginx 1.19.4+):
ssl_conf_command Options -Renegotiation;

# Verify with:
nginx -t && nginx -s reload
openssl s_client -connect example.com:443 -tls1_2

Apache Configuration

# Apache httpd — disable renegotiation
# mod_ssl directive (Apache 2.4.48+):
SSLRenegBufferSize 0
# Sets renegotiation buffer to 0, effectively refusing client-initiated renegotiation

# Alternative: restrict to TLS 1.3 only (eliminates renegotiation by protocol):
SSLProtocol -all +TLSv1.3

# Verify:
apachectl configtest && apachectl graceful

HAProxy Configuration

# HAProxy — disable renegotiation
# HAProxy inherits OpenSSL settings; set via ssl-default-bind-options:
global
    ssl-default-bind-options no-tls-tickets ssl-min-ver TLSv1.2 no-tlsv10 no-tlsv11
    # For TLS 1.3 only (preferred):
    ssl-default-bind-options no-tls-tickets ssl-min-ver TLSv1.3

# Verify renegotiation is not occurring:
haproxy -c -f /etc/haproxy/haproxy.cfg && systemctl reload haproxy

TLS 1.3 is the cleanest solution

Migrating entirely to TLS 1.3 eliminates renegotiation by design, removing it from the attack surface permanently without requiring explicit configuration. Check your client browser and API client compatibility before making the change.

Test in staging before production

TLS configuration changes can break client connectivity for older TLS implementations. Test the change against a full client compatibility matrix in a staging environment before applying to production. Check for error logs immediately after the production change for any clients that fail to connect.

Check Your TLS Configuration

DDactic's assessment includes TLS renegotiation checks and reports the specific configuration change needed for your server software.

Run a Free Scan
TLS RenegotiationTLS SecurityNginxApacheHAProxyDDoS Hardening