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).
> 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.
> 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.
> 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).
> At the moment, these are the only two options. In my
> opinion, the flexibility here is too constrained, merely adding a
> 2048bit setting means that eventually you need to add a higher
> setting.
OpenSSL needs to tell Postfix which grade is appropriate for a given
session. It does not. The cipher-suite is either "export" or
"non-export", and OpenSSL requests a corresponding EDH curve.
We should perhaps have called these parameters:
# 512 bits
smtpd_tls_dh_export_param_file
# 1024 bits historically, but possibly larger
smtpd_tls_dh_param_file
> Perhaps it is not possible to have a flexible and configurable
> bit length here?
It is not, until OpenSSL introduces a new callback that communicates
a more fine-grained security requirement to the application.
> What other changes could we come up with that could improve the state of
> things?
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 ...
> * 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!
> * 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
--
Viktor.
