Viktor Dukhovni <postfix-us...@dukhovni.org> writes: > On Wed, Oct 02, 2013 at 03:39:06PM -0400, Micah Anderson wrote: > >> From my understanding of the way postfix currently operates, there is no >> smtpd/stmp TLS setting that can be set that would provide a >> configuration that would result in a more 'hardened' configuration, >> without causing interoperability problems. If I am wrong, I'm very >> interested in knowing where. > > You get no benefit from hardening the Postfix SMTP server on port > 25 (tighter mandatory parameters on the submission port may work > for some). This has little to do with Postfix and everything to > do with the fact that SMTP servers accept messages from total > strangers (many of the clients don't support TLS at all).
Agreed. I suppose there is no way to achieve some middle ground of doing opportunistic encryption, but for those who are only talking with bad protocols and ciphers (or clear-text) do a non-permanent failure with a message about their bad protocol so at least some admin eventually may see that information (perhaps when the user complains that their messages are slow to be delivered). A more way would be to do a permanent reject, causing a bounce with a message that might cause some complaints to the admin. >> smtp_tls_fingerprint_digest = sha1 > > This setting hardly matters, but with OpenSSL 1.0.0 or later, or > with current Postfix releases, you can also use "sha256" if you > like. The sha1 digest is quite resistant to second preimage attacks, > even "md5" is reasonably secure in this context. > >> smtpd_tls_eecdh_grade = ultra > > Perhaps, though if the NIST curves are "cooked", it is not clear > that 512 bits is better than 256, and if not, then 256 may well be > enough. Here you need new non-suspect curves, and none are described > in relevant RFCs or available in OpenSSL at this time. When you say 'Here you need new non-suspect curves' - do you mean with using eecdh ciphers in general? If there is suspicion that they are cooked, maybe these should be disabled? >> What are some ways that we could improve the situation? > > You could disable SSLv3 in the SMTP client, and use only TLSv1, > TLSv1.1 or TLSv1.2. Do you mean in the MUA, or in the 'smtp' configurations in postfix? If the latter, what happens when you disable SSLv3 and connect to a remote MTA to make a delivery and they do not support anything but SSLv3? >> One obvious one to me is that Postfix should allow for DH parameters >> that are larger than 1024bit, 512bit is a joke, and 1024bit is not >> strong enough. > > Neither Postfix nor OpenSSL actually care about the size of the > prime in "smtpd_tls_dh1024_param_file". You can make it 2048 bits, > and likely get away with it. See recent thread on Exim TLS interop. > YMMV, some clients may choke on 2048-bit EDH (though more typically > these limited implementations are in are browsers, ... not MTAs). Interesting, what interoperability problems are there here? If you set the smtpd_tls_dh1024_param_file to a 2048bit file, what happens when a client chokes on this? Does it fall back to clear text, or a non-EDH cipher, or does it cause a connection reset... or? > Implement DNSSEC for your domain and publish DANE TLSA RRs: > > example.com. IN MX 0 mail.example.com. > mail.example.com IN TLSA 3 1 1 <SPKI sha256 digest> > ... plus appropriate RRSIG records ... Agreed here! >> * SMTP servers should provide a mechanism for rejecting a cleartext or >> poor ciphersuite connections from clients without compromising delivery. > > Only with submission. Rejecting weak TLS on port 25 is > counter-productive, the message is resent in the clear! Yeah, this is too bad. >> * SMTP clients need a clear and unambiguous signal that they can note >> that tells them not to try fallback behaviors when connecting to >> [certain hosts|MXes for certain domains] - using a hand-maintained >> tls_policy table isn't going to cut it. > > That's what DANE TLSA is for. Deploy Postfix 2.11-20130825 or > later, on a platform where OpenSSL is 1.0.0 or later (and EC > algorithms are not disabled is in Fedora or RedHat), make sure > /etc/resolv.conf points at 127.0.0.1 and that resolver is a DNSSEC > validating one. Then in main.cf: > > smtp_dns_support_level = dnssec > smtp_tls_security_level = dane Thanks for your answers! micah
