FREAK cipher-suite hygiene for Postfix
Now that the FREAK attack is widely disclosed, those of you who run SMTP servers that peer with clients that authenticate your server (be it via the traditional PKI or via DANE), might want to tighten-up your server cipher-suite settings just in-case:
smtpd_tls_exclude_ciphers = EXPORT, LOW
If nobody has yet elicited and factored any 512-bit RSA public keys from your server then your unpatched clients will be safe from the attack. (Not clear how you'd know this).
If your server might have already signed one or more export RSA keys then its clients are potentially exposed to the attack for the lifetime of the server's long-term RSA keys.
So, *after disabling* export grade algorithms, it may be prudent as appropriate to deploy new certificates. If you've published DANE TLSA records, follow the key rotation process described in:
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
Make sure to generate a new private/public key pair, rather than just re-use the existing key for a new certificate. Make sure to augment the TLSA record in DNS before deploying the new certificate, wait 2 TTLs or so, then deploy the new certificate and drop the obsolete instance of the TLSA record after.
Note that while Postfix clients that do mandatory TLS (authenticated or not) do not enable EXPORT ciphers, the reason the FREAK bug is important is that such clients accept ephemeral RSA key transport with a 512-bit key anyway, while ostensibly negotiating a cipher-suite that does regular RSA key transport. This is a failure to exclude state transitions that should be disallowed in the SSL/TLS protocol state-machine.
On Wed, Mar 04, 2015 at 07:53:18AM +0000, Viktor Dukhovni wrote:
Now that the FREAK attack is widely disclosed, those of you who run SMTP servers that peer with clients that authenticate your server (be it via the traditional PKI or via DANE), might want to tighten-up your server cipher-suite settings just in-case:
smtpd_tls_exclude_ciphers = EXPORT, LOW
If nobody has yet elicited and factored any 512-bit RSA public keys from your server then your unpatched clients will be safe from the attack. (Not clear how you'd know this).
If your server might have already signed one or more export RSA keys then its clients are potentially exposed to the attack for the lifetime of the server's long-term RSA keys.
It seems I substantially overstated the impact of the attack on Postfix. With export RSA key transport the server's signature of the ephemeral RSA key also binds the ClientHello.random value (as well as the ServerHello.random, but that could be replayed).
Therefore, the MiTM attacker would need to obtain a fresh signature over the ephemeral RSA key for each client handshake, which requires that the server continues to use the same ephemeral key.
This avoids turning each ephemeral key into a long-term key, the attack only works for as long as the same key is still in use by a given server and no longer.
So, *after disabling* export grade algorithms, it may be prudent as appropriate to deploy new certificates. If you've published DANE TLSA records, follow the key rotation process described in:
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
With Postfix each smtpd(8) process generates its own ephemeral RSA key the first time EXPORT ciphers are requested. Since Postfix smtpd(8) processes run for a limited amount of time (they exit after 100 client connections or 100s of idle time whichever is sooner) the attack on any one key is only effective for the lifetime of that process and only for additional connections to the *same* process.
So if you disable EXPORT ciphers on the server, and "postfix reload" you're done. There is no need to replace long-term keys.
participants (1)
-
Viktor Dukhovni