On Thu, Jan 14, 2016 at 11:54:13PM -0500, Curtis Villamizar wrote:
> > > > > smtp_tls_ciphers = high
> > > >
> > > > Usually best to leave this at "medium". This is opportunistic
> > > > TLS, and if high fails, you'll send cleartext, which is NOT
> > > > stronger than medium.
> > >
> > > That's actually fine if it actuall fell back. Comcast didn't fall
> > > back, it tried secondary MX, then TEMPFAIL. Its only intended for
> > > internal servers that are supposed to bring up TLS with a trusted key
> > > and then also SASL authenticate. Otherwise I might just leave it at
> > > none.
> >
> > This is an SMTP *client* setting for your outbound connections,
> > and has nothing to do with what happens when Comcast sends you
> > mail. My point is that this is unwise, regardless of Comcast.
>
> This is so that the MTA can authenticate to the MDAs. My MDA config
> goes have smtpd_tls_req_ccert = yes.
Use dedicated transports in master.cf for connections to your MDAs,
say, the "relay" transport or a similar clone, and configure appropriate
master.cf overrides:
master.cf:
relay unix - - y - - smtp
-o smtp_tls_ciphers=$relay_tls_ciphers
main.cf:
relay_tls_ciphers = high
Do not set enforce overly stringent TLS settings for outbound
opportunistic TLS connections to the Internet at large. Yes,
admittedly peers with just "MEDIUM" ciphers are becoming increasingly
rare, so you might not feel much pain, but there's no win from
enforcing stronger ciphers if when you don't get them, Postfix
fails over to cleartext.
> > smtpd_tls_req_ccert=yes requires trusted TLS, that is the client's
> > certificate must be issued by a trusted CA. For port 587 only,
> > and understand the consequences.
>
> The difference would be if you have:
>
> smtpd_tls_ask_ccert = yes
> smtpd_tls_req_ccert = no
> smtpd_tls_auth_only = trusted
I see, allow untrusted TLS, but only offer SASL to clients with
trusted certs, and what are the others supposed to do?
> then the same config supports opportunistic TLS for the outside
> without client key (they just don't provide one) but does allow an
> internal client to authenticate and get relaying.
Relaying is on port 587, where opportunistic connections simply
don't happen. On port 25 you should have no submission clients.
So this is a non-issue. Just unconditionally disable SASL on port 25.
> As I mentioned way down at the bottom, another and probably better
> solution is to relay through the MSA.
Relay through the MSA, or some other dedicated port. You can use
client cert authorization for that, and not bother with SASL at
all.
> > > Relevant parts:
> > >
> > > ASN1 OID: secp384r1
> > > Signature Algorithm: ecdsa-with-SHA256
> >
> > Well, that's probably why comcast is having trouble, they likely
> > don't support ECDSA. You really should field an RSA certificate,
> > along with the (still bleeding-edge) ECDSA certificate.
>
> That was my first theory but stated a different way. I said early on
> that they are probably running older (openssl 1.0.1) code that doesn't
> support secp384r1.
Except that 1.0.1 does support EC with that curve, but not on RedHat
systems (very cautious lawyers).
> > > Not supported in openssl 1.0.1, but that is > 1 year old version.
> >
> > Actually, even 1.0.0 supports ECDSA, but not on RedHat/CentOS
> > systems, for patent-fear reasons.
>
> But not secp384r1. That came with 1.0.2.
This is not true. It was even present in 1.0.0, except with RedHat:
$ OpenSSL_1_0_0/bin/openssl version
OpenSSL 1.0.0t-dev xx XXX xxxx
$ OpenSSL_1_0_0/bin/openssl ecparam -list_curves | grep 384
secp384r1 : NIST/SECG curve over a 384 bit prime field
> > No, it means that Comcast can't perform a TLS handshake because
> > they don't support ECDSA.
>
> I guess we agree that is most likely the problem.
Yes. For interoperability, deploy RSA certs in addition to or
instead of ECDSA certs.
> > The roles of the client and server are very differnt. Just
> > because the settings are the same, does not make them right,
> > even if they are right for the other case.
> >
> > http://www.postfix.org/TLS_README.html#client_tls_limits
>
> I'm going to keeping this strong and keeping an eye out for cipher
> mismatch. Until comcast a week or too ago there was no problem.
Forcing maximally strong settings gives you no additional security,
it reduces security, by forcing cleartext fallback by less capable
peers. Yes, the absolutely weakest algorithms that nobody needs
anymore should be turned off to minimize attack surface, but with
opportunistic TLS you should avoid the temptation to turn it up to
11.
> Thanks for the advice but I'm going to keep things at strong. I will
> take your earlier advice on changing smtp[d]_tls_exclude_ciphers.
Note that "strong" actually means less secure for the peers that
are not capable of meeting that standard. See RFC7435.
> Since my use of TLS is primarily for internal connections where
> smtpd_tls_auth_only is used, I haven't made anything I care about
> weaker by making setting strong or using a strong key, even if it is
> still bleeding-edge. See bottom of this reply.
You can use dedicated ports and IP addresses for intramural traffic.
No need to mix that in in the same ports as the unwashed massed.
--
Viktor.
