DevHeads.net

Disable SSL/TLS renegotiation

Hello postfix-users,

While checking the SSL configuration of a Postfix server, I noticed that
so-called "Client-initiated secure renegotiation" is available at
Postfix by default.
You can verify it with following openssl command and press "R" once the
connection is successfully established:

openssl s_client -connect <hostname/IP>:25 -starttls smtp

250 DSN
R
RENEGOTIATING
depth=2 C = US, O = XXX, OU = <a href="http://www.xxx.com" title="www.xxx.com">www.xxx.com</a>, CN = XXX Root CA
verify return:1
depth=1 C = US, O = XXX, OU = <a href="http://www.xxx.com" title="www.xxx.com">www.xxx.com</a>, CN = XXX Server CA
verify return:1
depth=0 C = XX, ST = XXX, L = XXX, O = XX, CN = XXX
verify return:1

The problem with SSL renegotiation in association with DoS attacks is
already known. You can find a lot of information on the Internet, but
mostly related to HTTPS.

<a href="https://blog.qualys.com/ssllabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks" title="https://blog.qualys.com/ssllabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks">https://blog.qualys.com/ssllabs/2011/10/31/tls-renegotiation-and-denial-...</a>

There is also a modified version of a well known exploit that performs
the same attack against SMTP (STARTTLS) protocol. It establishes several
connections and initiates the renegotiation several times.
I ran this exploit against a postfix server. It was possible to increase
the load significantly with only 30 threads:
- Attackers client with 1 core CPU and 0,60 load average during the
attack. (30 SMTP connections)
- Target server with 4 core CPU and 17.0 load average during the attack.
(30 SMPT connections)

Are there already plans to make "Client-initiated secure renegotiation"
support in Postfix disengageable? I would very much appreciate it if I
could switch off this function.

Best regards,

Viktor

Comments

Re: Disable SSL/TLS renegotiation

By Viktor Dukhovni at 07/11/2018 - 10:04

When you configure TLS handshake rate limits, they apply equally
to new connections and renegotiation. If you don't configure TLS
handshake rate limits, it is not clear why you'd want to restrict
renegotiation, unless you're trying to use connection rate limits
as a proxy for TLS rate limits.

You can rate limit non-resumption TLS handshakes:

<a href="http://www.postfix.org/postconf.5.html#smtpd_client_new_tls_session_rate_limit" title="http://www.postfix.org/postconf.5.html#smtpd_client_new_tls_session_rate_limit">http://www.postfix.org/postconf.5.html#smtpd_client_new_tls_session_rate...</a>

If you're linking against OpenSSL 1.1.0h or later, you can set the
SSL_OP_NO_RENEGOTIATION SSL option:

<a href="http://www.postfix.org/postconf.5.html#tls_ssl_options" title="http://www.postfix.org/postconf.5.html#tls_ssl_options">http://www.postfix.org/postconf.5.html#tls_ssl_options</a>

tls_ssl_options = 0x40000000

That value of 0x40000000 has a completely different effect in OpenSSL
1.0.x (which is not ABI-compatible with OpenSSL 1.1.x), where it
set the

SSL_OP_NETSCAPE_DEMO_CIPHER_CHANGE_BUG

option, and has no effect with OpenSSL 1.1.0 at patch levels lower
than "h". So do not do this with earlier OpenSSL releases.
The latest patch release is OpenSSL 1.1.0i.

You best bet is the TLS session rate limit.