In message <[email protected]>
Viktor Dukhovni writes:
> On Fri, Jan 22, 2016 at 03:14:22PM -0500, Curtis Villamizar wrote:
>
> > You might
> > also want to report that the keys they use are less than LOW security
> > but that might be a feature.
>
> You're mistaken. These ciphers are HIGH.
>
> > Note that none of the ciphers used by comcast.net support even low
> > strength and forward secrecy.
>
> You're mistaken.
>
> > So for me falling that far back to encoding in 56 bit DES and a SHA1
> > MAC seems a bit too far backwards to go (back to SSLv3 days).
>
> You're mistaken.
>
> --
> Viktor.
Viktor,
Yes. I rechecked. I was mistaken. These four are high and offer
forward secrecy.
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
Due to the naming used:
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
I did a few openssl ciphers commands and greps for CBC-SHA and
CBC3-SHA and got the wrong ones based on the naming.
I redid this with openssl ciphers -V and used to hex codes. The last
two are MEDIUM. The other six are HIGH. Four offer forward secrecy,
the ones starting the DHE.
My understanding is that RC4 has multiple proven vulnerabilities so
not using the last two is justified. SHA1 should be avoided, but
admitedly no one would bother with the computational load needed for a
SHA1 attack on our opportunistic TLS email, particularly no spammer
trying to find a relay to use.
You did not respond to the rest of the email. Any comments on the
rest of it?
So for now I'll stick with what I have as it is not a
problem otherwise and add:
smtpd_discard_ehlo_keyword_address_maps =
cidr:/etc/postfix/no-tls-for-you
no-tls-for-you:
69.252.207.0/24 starttls
96.114.154.0/24 starttls
69.252.76.0/24 starttls
76.96.68.0/24 starttls
2001:558:fe16:19::/64 starttls
2001:558:fe21:29::/64 starttls
That covers the comcast.net mail servers according to
https://postmaster.comcast.net/outbound-mail-servers.html
In reviewing the logs very few non-spammer domains seem to be failing.
The most concerning non-spammer is cloud9.net. I'm still considering
keeping the primary MX with the same sort of key and using either no
TLS or a weaker key on the secondary MX.
I'll also run tcpdump on the cloud9.net addresses and run it through
tshark and see what the problem is there. If it is simply that they
don't use ECDSA or AESGCM, but they do offer something reasonable,
then I'll consider creating an alternate key. Otherwise I'll just add
them to the cidr file. I hope someone at cloud9.net is reading this
(they do host the postfix mailing lists), but if not I'll send
off-list email.
Either way I'll continue to watch the logs (or cron will) for
'SSL_accept error' lines (fail) and for 'Trusted TLS connection from'
(trusted) or 'TLS connection established from' (anon or untrusted).
Having a strict primary MX and a weak secondary allows me to do this
logging without dropping mail.
Note that smtpd_tls_ask_ccert does no damage as the client key is
accepted as untrusted and then AUTH is not offered but relay to my
MDAs still happens [...]
Ammending the above, now knowing that the comcast.net keys are high.
I might just add a longish RSA key as a solution for comcast.net but
keeping high in place. That might also solve the cloud9.net and one
or two others that are non-spammers and currently fail and fall back
to the secondary MX.
[aside: Perhaps ECDSA-AES256-GCM-SHA384 was a bit too much for email.
It seems to not upset HTTPS and browsers. OTOH- TLSA/DANE support in
browsers is non-existant without plugins but available for email.]
Thanks again.
Curtis
