Hi Viktor,
I really appreciate all of the good information you have provided. We
are going in circles in a few places because we have different goals.
See comments inline and at the end of this message.
In message <20160114212645.gk...@mournblade.imrryr.org>
Viktor Dukhovni writes:
>
> On Thu, Jan 14, 2016 at 03:53:23PM -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.
This doesn't seem to have caused any problem at all.
> > > > smtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
> > >
> > > This is worse, your opportunistic TLS is constrained to
> > > TLSv1.
> >
> > The lines are the same. What I'd like is TLSv1.2 only. Documentation
> > recommended the !format rather than the "legacy" format (in case there
> > is later a 1.3 defined, for example), there is no TLSv1.0 and TLSv1
> > refers to TLSv1.x. So no good way to exclude TLSv1.0 afaik (afaik is
> > now past tense, see below).
>
> To exclude TLSv1, use "!TLSv1". Do check the docs for syntax,
> that's what they're there for.
By now I figured this out (Note the afaik is now past tense, see
below). Sorry if I'm seeming dense.
> > > > smtpd_tls_ask_ccert = yes
> > >
> > > To you do anything with client certs? If not, don't request
> > > them.
> >
> > Since the primary reason for having this was for my own hosts,
> > particularly the MSA, the intent was to use them if I could.
>
> Set that on port 587 only, master.cf.
I have a separate MSA. Completely different host (BSD jail on a VM).
> > Unfortunately I can't find an option that requires trusted TLS before
> > AUTH, just any TLS (no smtpd_tls_auth_only = trusted, just yes/no).
>
> 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
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.
As I mentioned way down at the bottom, another and probably better
solution is to relay through the MSA. Note that most of my hosts have
to relay with smart host because they are IPv6 only and need to relay
to get to the IPv4 only world.
> > > > smtpd_tls_cert_file = /etc/postfix/cert.pem
> > > > smtpd_tls_key_file = /etc/postfix/key.pem
> > >
> > > What kind of key is that? RSA or ECDSA? Can you
> > > post the output of:
> > >
> > > openssl x509 -in /etc/postfix/cert.pem -noout -text | egrep -v
> > > ':.*:.*:'
> >
> > 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.
> > 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 OK if the only thing I want authenticated is my own MSA and
> > MDA servers.
>
> 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.
My tcpdump has not picked up anything. The MTA is a BSD jail and
tcpdump is running on the VM hosting the jail. I may have to restart
the jail and make bpf available to the jail.
> > > > smtpd_tls_ciphers = high
> > >
> > > This is a bad idea, leave it at medium.
> > >
> > > > smtpd_tls_exclude_ciphers = aNULL MD5 DES
> > >
> > > This is not needed.
> >
> > same as smtp.
>
> 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.
> You're working too hard trying to make your system more secure,
> and shooting yourself in the foot making it less secure as a result.
> Apply the suggested settings, they're better, leave more things
> at their defaults.
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.
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.
> > > > smtpd_tls_loglevel = 2
> > >
> > > Level 1 is just right, 2 is too much.
> >
> > Maybe so. Isn't hurting anything.
>
> Actually it severely hampers performance under load, because syslog
> gets overwhelmed with messages.
I'm just doing this while watching the occasional comcast message.
This is a lightly loaded server.
> > I thought (apparently incorrectly) that TLSv1 was TLSv1.x so I didn't
> > include it. Documentation was not clear on that.
>
> TLSv1 is just TLS 1.0. That's what OpenSSL called it, (and then
> later 1.1 came along. At the time the only previous examples
> were SSLv2 and SSLv3, so TLSv1 made sense.
Yep.
> > > > smtpd_tls_session_cache_timeout = 300
> > >
> > > Longer is better, especially with Postfix 2.11+ and session
> > > tickets. Let the default stand.
> >
> > Hasn't been a problem. What would it break?
>
> SMTP clients connect less often than HTTP clients, longer session
> time improve session reuse and cost you nothing (because the
> session state is client-side).
There have been bugs here and this is a lightly loaded server so I'm
OK keeping this short.
> > > > tls_disable_workarounds = 0xFFFFFFFF
> > >
> > > Are you sure that's a good idea? This is opportunistic TLS.
> >
> > This is TLS between my servers where I happen to get opportunistic TLS
> > as a result of having a STARTTLS.
>
> Well it also affects inbound mail from Comcast and others, and
> outbound mail to the world.
Lets go through the list:
SSL_OP_MICROSOFT_SESS_ID_BUG - SSLv2 only
SSL_OP_NETSCAPE_CHALLENGE_BUG - SSLv2 only
SSL_OP_LEGACY_SERVER_CONNECT - legacy insecure renegotiation (no thanks)
NETSCAPE_REUSE_CIPHER_CHANGE_BUG - disabled by default
SSLREF2_REUSE_CERT_TYPE_BUG - has no effect.
MICROSOFT_BIG_SSLV3_BUFFER - has no effect.
MSIE_SSLV2_RSA_PADDING - disabled by default
SSLEAY_080_CLIENT_DH_BUG - OS X 10.8..10.8.3 broken for ECDHE-ECDSA
TLS_D5_BUG - OS X 10.8..10.8.3 broken for ECDHE-ECDSA
TLS_BLOCK_PADDING_BUG - OS X 10.8..10.8.3 broken for ECDHE-ECDSA
TLS_ROLLBACK_BUG - disabled by default (in openssl)
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS - disable SSLv3/TLSv1.0 vuln fix
CRYPTOPRO_TLSEXT_BUG - applies to GOST only
I don't think anyone is running old enough code that disabling any of
this matters. Maybe for a web server it might.
> --
> Viktor.
>
> > Can't use smtpd_tls_req_ccert on MTA.
> >
> > The MSA needs to be a little weak due to cell phones sending mail. So
> > can't use smtpd_tls_req_ccert on MSA either (for now) and there is no
> > smtpd_tls_auth_only = trusted though it would be real nice to have.
>
> How would that differ from "smtpd_tls_req_ccert". What would
> "trusted" mean?
smtpd_tls_req_ccert = yes means all connections must provide a client
cert. smtpd_tls_auth_only = trusted would mean that for auth to be
offered a client certificate must have been provided and that is for
internal hosts only.
----------------------------------------
I fully understand your points about using medium and other settings
that more reliably support opportunistic TLS to more places. But that
is not a goal. If comcast mail falls back to unencrypted no worries.
I'm still going to use very strong encryption but for other reasons.
A while back I decided that MSA and MTA configs were sufficiently
different to use separate servers (jails really so it is not for any
loading reasons, and jails on a VM set aside for MSA/MTA only). The
secondaries are at a different site, so different server/VM/jails.
So I use port 25 on separate MSAs. Nothing uses port 587.
A concern I had was internal mail going to the MTA rather than MSA due
to my own host not being configured with relayhost. Once I'm sure
that all my hosts have been updated to relayhost to an MSA and the
MSAs to relay to the right MDA, I can tailor smtpd_ TLS config on the
MTA to better suit opportunistic TLS, or just set
smtpd_tls_security_level = none on the MTA.
I actually didn't really care much about opportunistic TLS. It just
seemed to come for free and gave me no trouble until recently and only
for one provider.
For now I'm going to use smtpd_discard_ehlo_keyword_address_maps as
Wietse suggested at the very beginning of this thread.
Curtis
