Skip to content

TLS Client-Initiated Renegotiation DoS Vulnerability

TLS Client-Initiated Renegotiation DoS Vulnerability

Description

This vulnerability indicates that the server allows unlimited client-initiated TLS renegotiation, which can be exploited for denial-of-service attacks by forcing the server to perform expensive cryptographic operations.

Client-initiated renegotiation vulnerability occurs when TLS servers allow clients to repeatedly request renegotiation of TLS parameters without adequate rate limiting. Since the server must perform computationally expensive cryptographic operations during renegotiation, this can be exploited to consume server resources with minimal attacker effort.

How It Works:

  1. Attacker establishes a TLS connection to the target server
  2. Attacker repeatedly triggers TLS renegotiation requests (potentially thousands per second)
  3. Server's CPU becomes saturated processing these renegotiation handshakes
  4. Legitimate users experience severe performance degradation or complete service unavailability

Requirements:

  • TLS server allowing client-initiated renegotiation
  • Absence of rate limiting or throttling on renegotiation attempts
  • Ability to establish a connection to the target server

Example Scenario: An attacker establishes a small number of connections to a banking website's HTTPS server, then initiates hundreds of renegotiation requests per second on each connection. The server's CPU utilization spikes to 100% as it processes these cryptographic operations, causing legitimate transactions to time out or fail completely. With just a few attack connections, the attacker achieves an effective denial of service using minimal bandwidth.

The attack exploits the computational asymmetry between client and server during TLS renegotiation, where the server must perform significantly more work than the client. This makes it a particularly efficient DoS vector that can affect any service using TLS, including HTTPS, SMTP over TLS, and other secure protocols.

Recommendation

To mitigate TLS client-initiated renegotiation vulnerabilities, implement the following strategies:

Primary Mitigations:

  1. Disable Client-Initiated Renegotiation - The most effective mitigation is to completely disable client-initiated renegotiation while still allowing server-initiated renegotiation when necessary.

  2. Implement Renegotiation Rate Limiting - If client renegotiation cannot be disabled, implement strict rate limiting on how frequently a client can request renegotiation.

  3. Update TLS Libraries - Ensure all TLS implementations are updated to include protections against renegotiation-based DoS attacks.

Implementation Examples:

# Nginx configuration
# Disable client renegotiation
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.2 TLSv1.3;

# Apache configuration
# Disable client renegotiation while keeping server renegotiation
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOptions +NoRenegotiate

# OpenSSL configuration (for custom applications)
SSL_CTX_set_options(ctx, SSL_OP_NO_CLIENT_RENEGOTIATION);

For Load Balancers:

# F5 BIG-IP configuration
modify ltm profile client-ssl my_ssl_profile {
    renegotiation disabled
}

Additional Safeguards:

  • Deploy a Web Application Firewall (WAF) to detect and block excessive renegotiation requests
  • Implement connection and request rate limiting at the network level
  • Consider upgrading to TLS 1.3 which eliminates renegotiation completely
  • Configure network timeout policies to close connections that attempt excessive renegotiation

Verifying Your Configuration:

# Test for client renegotiation using OpenSSL
openssl s_client -connect example.com:443 -tls1_2
# Then type "R" and press Enter to request renegotiation
# If the connection terminates or returns an error, client renegotiation is disabled

Standards

  • SOC2_CONTROLS:
    • CC_6_7
    • CC_7_1
  • CCPA:
    • CCPA_1798_150
  • GDPR:
    • ART_32
  • PCI_STANDARDS:
    • REQ_2_3
    • REQ_6_5
    • REQ_11_3