Limit SSL Handshake Rate

Limit SSL Handshake Rate controls how frequently a single client IP address can initiate TLS handshakes, reducing the gateway CPU and connection resources consumed by abnormal handshakes. This feature is an extended connection protection capability for CC protection.

# Use Cases

• A single client IP address repeatedly creates new TLS connections.
• Abnormal clients do not reuse connections and continuously consume TLS handshake resources.
• Connection establishment must be limited before HTTP page rules take effect.

If attack traffic completes the TLS handshake and continues to request application endpoints, also use request-layer protection such as Limit Request Rate.

# How It Works

OpenResty Edge measures the SSL handshake rate by client IP address. Requests below the regulating threshold are unaffected. Requests above the regulating threshold but below the rejection threshold are delayed. Requests above the rejection threshold are rejected with HTTP status code 503. If both thresholds are set to the same value, there is no regulating range, and requests above that rate are rejected immediately.

At present, this feature supports only client IP addresses as the measurement key.

# Configuration

1. In Edge Admin, open the SSL configuration page for the target application.
2. Find SSL handshake rate limiting and enable the feature.
3. Set the regulating threshold, rejection threshold, and their units.
4. Save the configuration and publish the application.

# Parameters

• Regulate At: Handshakes below this rate are unaffected. Requests above this rate but below the rejection threshold are delayed.
• Reject At: Requests above this handshake rate are rejected with HTTP status code 503.
• Unit: Set the thresholds in requests per second or requests per minute.

# Verification

In a controlled environment, continuously send HTTPS requests that establish new TLS connections from the same client IP address. Observe the response below the regulating threshold, the delay within the regulating range, and the HTTP 503 response above the rejection threshold. Reusing an existing TLS connection does not create a new handshake and is not suitable for testing this feature.

# Considerations

• Multiple users behind the same NAT gateway or forward proxy share one client IP address. A threshold that is too low can affect all of them.
• TLS connection reuse, normal traffic peaks, and client network retries all affect the handshake rate. Adjust the thresholds gradually based on monitoring data.
• This feature controls only TLS handshakes. It does not replace HTTP request rate limiting or application endpoint access controls.