In message <20160115051749.gl...@mournblade.imrryr.org> Viktor Dukhovni writes: > 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.
Viktor, Thanks. I'll do this when I install the new server. If so I might have a rather long -o argument. > > > 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? There are three cases: 1. Anon TLS - they don't provide a cert 2. client provides cert with TLSA - trusted, they ignore the AUTH 3. internal client has trusted cert and SASL pw - they can relay Lets leave this suggestion to die. I don't need this as there is a better way to do things (bottom of prior email). > > 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. See bottom of the prior email. > > 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. By MSA here I mean another host that serves as MSA (on port 25) not same host on port 587. Both approaches work. See bottom of prior email. > > > > 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). OK. If you say so. My emperical experience indicates that this version does not support it. OpenSSL 1.0.1p-freebsd 9 Jul 2015 > > > > 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 Maybe its not in FreeBSD either except the version from ports collection. Do you have a reference to the legal issue handy? > > > 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. OK. I hear you. Or disable opportunistic TLS at least for now. > > > 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. Somehow you missed this statement (sic) "I don't care about opportunistic TLS. It came for free and didn't cause any trouble until now". > > 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. See prior sentence. > > 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. When I migrate to the new physical server RSN, I'll redo the configs. For now, I'll keep what I have because I have other things to do and things are working well enough. > -- > Viktor. Oops - you cut off the bottom of the old reply. Anyway my prior email explained how I plan to change my server setup. Thanks again. Lets not continue to beat a dead horse. Curtis
