What are the generally-accepted “best practices” for deploying SMTP STARTTLS? What protocols and cipher suites should be offered?
I currently have a Postfix server using a mostly-default config that will offer STARTTLS on incoming connections and tries to use STARTTLS on outgoing connections. However, as far as I can tell, it:
doesn’t validate remote certificates
apparently still accepts cipher suites like RSA_EXPORT_WITH_RC4_40_MD5
However, since STARTTLS is optional anyways and plain unencrypted mail will still be accepted, it’s not clear to me that this is a problem. Is it?
What happens if a remote SMTP server tries to send me mail but does not support any of the offered TLS cipher suites? Will the server retry without TLS? Is it safe to duplicate the SSL Labs A+ config with only PFS for an SMTP server?
Also, how useful are TLS features like OCSP stapling and session resumption for SMTP STARTTLS?
You can tweak the security level you want for outgoing mails using smtp_tls_security_level. I personally prefer dane : encryption is mandatory to server with a dnssec signed TLSA record (for example, this server as a TLSA record), and fallback to opportunistic encryption if not.
For incoming mail the parametter is smtpd_tls_security_level. The recommended value is may otherwise you will not be able to receive mails from server that no not supporl TLS.
For hardening your mail server security, I recommend you to publish a TLSA record for your mail server in your dns zone. Hence, other servers with smtp_tls_security_level=dane will make encryption to your server mandatory. Beware that if the TLSA record and the certificate presented by your mail server do not match, you will stop receiving email from smtp_tls_security_level=dane people.
Hi rqou, here’s a few things I’d propose as best practices:
Don’t break SMTP. If you break delivery in the name of security, the battle may be won but the war is lost.
Always negotiate the strongest available cipher available
do not validate remote certificates, since the majority of them will fail validation
to combat MITM attacks, maintain a db of hosts whose certificates have validated in the past, and require those to validate in the future. Some very large providers (like Google) have valid certs, so this will end up covering a large portion of email traffic.
there are plenty of broken implementations of STARTTLS. When delivering to a remote and STARTTLS fails, store a “don’t try STARTTLS to this host next time” flag that is cleared after the next attempt. That way, mail still flows, and when the remote fixes their STARTTLS, traffic will automatically start getting opportunistically encrypted.
According to your line of reasoning, the Best Practice for SMTP STARTTLS is to not use STARTTLS at all, since opportunistically encrypting email is “a lot of work for marginal gain.”
Maintaining remote state information may be a lot of work for you but that doesn’t mean it’s that way for everyone. For some of us, it’s a half dozen LOC to insert a key/val into Redis after a successful validation and a half-dozen more LOC to check the key-value store when future validations fail. It’s not hard. At all. Anyone doing remotely advanced filtering should have this ability already, as TLS certificate validation should be an input into their remote reputation engines.
Yes, TLS validation is premised on reliable functioning DNS. Are there edge cases where DNS can be subverted? Certainly. Should we forego any type of security improvements that involve DNS? To each their own, based on the thickness of their tinfoil hat.