In message <20160122041647.gh25...@mournblade.imrryr.org>
Viktor Dukhovni writes:
> On Thu, Jan 21, 2016 at 10:55:19PM -0500, Curtis Villamizar wrote:
>
> > It took a while to get a dumpfile. My tcpdump command only covered a
> > subset of comcast.net mailhosts.
> >
> > This has a failed TLS negotiation and a few packets from a next
> > attempt. The log entry below covers this first connection.
>
> Comcast's Client Hello:
>
> $ tshark -V -r file.pcap -T text
> ...
> Secure Socket Layer
> SSL Record Layer: Handshake Protocol: Client Hello
> Content Type: Handshake (22)
> Version: TLS 1.0 (0x0301)
> Length: 110
> Handshake Protocol: Client Hello
> Handshake Type: Client Hello (1)
> Length: 106
> Version: TLS 1.2 (0x0303)
> Random
> gmt_unix_time: Jan 21, 2016 21:42:08.000000000
> random_bytes:
> F015DF3A10F02A3715060148AFF41E28315A20155496A43A...
> Session ID Length: 0
> Cipher Suites Length: 18
> Cipher Suites (9 suites)
> 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)
> Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
> ...
>
> No sign of ECDSA support, or AESGCM, or anything else bleeding
> edge. Similarly configured MTAs will not be able to complete TLS
> handshakes with your server unless you also deploy an RSA certificate.
>
> --
> Viktor.
Viktor,
The bug that it doesn't fall back then is likely because comcast mail
servers are running sendmail or something else other than postfix. If
you do know someone at comcast, then please report that. You might
also want to report that the keys they use are less than LOW security
but that might be a feature. Please also ask when opportunistic TLS
was enabled.
Note that none of the ciphers used by comcast.net support even low
strength and forward secrecy.
cat <<EOF | egrep 'TLS_ECDHE_|TLS_DHE_|TLS_ADH_|TLS_EDH_'
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)
EOF
yields:
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_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
These four support forward secrecy. But these and all the comcast
ciphers are less than low strength and would be excluded with !LOW.
They would be high with CBC3_SHA and CBC3_SHA is not bleeding edge.
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).
The opportunistic TLS offered by comcast.net isn't much better than no
TLS at all. 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 (which in the two cases today allowed connections
from google.com allowing spammers using gmail to connect - one sending
to spam@ - obviously having harvested that from a hidden div in web
page of mine requesting help building spam filters - I guess even
gmail has spammers openning free accouts).
Thanks for all of the help and good advice. Thanks also to Wietse who
suggested using smtpd_discard_ehlo_keyword_address_maps.
Curtis
