FREAK cipher-suite hygiene for Postfix
Viktor Dukhovni
ietf-dane at dukhovni.org
Wed Mar 4 08:54:38 CET 2015
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.
--
Viktor.
More information about the dane-users
mailing list