[BlueOnyx:17819] Re: TLS Error - fact finding tour
Michael Stauber
mstauber at blueonyx.it
Tue Jun 16 22:39:11 -05 2015
Hi Richard,
> I have done all of that, restarted CCeD and ran the other script as above
> but still getting some TLS handshake failed messages and deferred emails.
>
> Any other suggestions?
What version of BlueOnyx is that?
I did some more digging in between and we're in between a rock and a
hard place here. And it also outlines that the days of 5106R are counted.
I just used NMAP to check what ciphers we actually still support now
that Sendmail is secured. Here is the command that you can use that to
check yourself:
nmap --script ssl-enum-ciphers -p 465 hostname.domain.com (or IP)
Example:
nmap --script ssl-enum-ciphers -p 465 127.0.0.1
First let us take a look at a 5106R *without* the base-email fixes applied:
Nmap scan report for 5106r.smd.net (208.77.221.202)
Host is up (0.00055s latency).
PORT STATE SERVICE
465/tcp open smtps
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_EXPORT_WITH_DES40_CBC_SHA - weak
| TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_EXPORT_WITH_DES40_CBC_SHA - weak
| TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: weak
As you can see above: SSLv3 is still enabled (bad idea) and TLSv1.0 is
supported. TLSv1.2 is not available as the OpenSSL on CentOS5 doesn't
support it. Additionally the two protocols support a few really weak
ciphers, too. Including the worthless EXPORT ciphers.
Once this is locked down with the base-email fixes it looks like this:
Nmap scan report for 5106r.smd.net (208.77.221.202)
Host is up (0.00054s latency).
PORT STATE SERVICE
465/tcp open smtps
| ssl-enum-ciphers:
| SSLv3: No supported ciphers found
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
|_ least strength: strong
So that leaves TLSv1.0 and *just* four strong ciphers.
Now let us try a CentOS 6 box (5107R, 5108R, 5207R or 5208R):
Nmap scan report for 5208r.smd.net (38.114.102.15)
Host is up (0.00012s latency).
PORT STATE SERVICE
465/tcp open smtps
| ssl-enum-ciphers:
| SSLv3: No supported ciphers found
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.1:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| compressors:
| NULL
|_ least strength: strong
That looks a hell of a lot better. We got:
- SSLv3 disabled
- TLSv1.0
- TLSv1.1
- TLSv1.2
All in all we got about 20 different protocol and cipher combinations
with that. For a total of 10 *unique* ciphers. There sure will be
something for even the most dilapidated other mailserver that we want to
talk to. If not? My bad.
Now let us take a look at CentOS 7 and 5209R:
Nmap scan report for 5209r.smd.net (38.114.102.16)
Host is up (0.000071s latency).
Other addresses for 5209r.smd.net (not scanned): 38.114.102.16
PORT STATE SERVICE
465/tcp open smtps
| ssl-enum-ciphers:
| SSLv3: No supported ciphers found
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.1:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| compressors:
| NULL
|_ least strength: strong
- SSLv3 disabled
- TLSv1.0
- TLSv1.1
- TLSv1.2
And in between them I count 28 strong ciphers with 12 *unique* ciphers.
So let us go back to 5106R again. What did we really take away?
In essence we removed SSLv3 *and* disabled three horribly weak TLSv1.0
ciphers:
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA - weak
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak
TLS_RSA_WITH_DES_CBC_SHA - weak
So let us use the BlueOnyx list server as an example (as it is still on
a 5106R). The emails it sent since the last logrotate used the following
ciphers:
[root at lists /]# cat /var/log/maillog|grep cipher| awk -F 'cipher=' '{
print $2 }'|cut -d , -f1|sort -u
AES128-SHA
AES256-SHA
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
Now there is just one email sitting in the queue right now which has
apparent TLS issues on the *receiver* side:
[root at lists /]# mailq
/var/spool/mqueue (14 requests)
-----Q-ID----- --Size-- -----Q-Time-----
------------Sender/Recipient-----------
t5GH07rD001380 6100 Tue Jun 16 12:00 <blueonyx-bounces at mail.blueonyx.it>
(Deferred: 403 4.7.0 TLS handshake failed.)
<XXX at XXX.com.uy>
I XXX'ed out the address. And then I did run NMAP against that email
server to see what it actually supports:
465/tcp open smtps
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA - weak
| TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_DSS_WITH_DES_CBC_SHA - weak
| TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA - weak
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_EXPORT_WITH_DES40_CBC_SHA - weak
| TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak
| TLS_RSA_EXPORT_WITH_RC4_40_MD5 - weak
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: weak
The only strong ciphers it supports:
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
And we currently support *none* of these. Because our OpenSSL doesn't
have them on 5106R. *AND* anything RC4 based is considered broken and
not 'strong' at all.
Now *if* our 5106R would still support TLS_RSA_WITH_RC4_128_SHA or
TLS_RSA_WITH_RC4_128_MD5 (and we turned those off), then we could
*still* talk to this host.
In fact: TLS_RSA_WITH_RC4_128_SHA or TLS_RSA_WITH_RC4_128_MD5 *appear*
to be still widely supported by pretty much all mailservers. Both are
crappy ciphers. RSA alone? Bad. RC4? Consider it broken. SHA? On its own
it doesn't pull that cart out of the ditch either. MD5? Yikes! Really
bad idea for a checksum.
But all things considered I'll now add TLS_RSA_WITH_RC4_128_SHA again to
the mix of allowed ciphers. I don't like it, but for the sake of
compatibility we might need it. At least for now.
The sad part? I need to allow ciphers with MD5 checksum as well. I
couldn't find any way to allow it without allowing MD5 checksums again,
too. So the result on a 5106R will be this:
Nmap scan report for 5106r.smd.net (208.77.221.202)
Host is up (0.00051s latency).
PORT STATE SERVICE
465/tcp open smtps
| ssl-enum-ciphers:
| SSLv3: No supported ciphers found
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
| NULL
|_ least strength: strong
That gives us two additional ciphers on 5106R. On 5209R we "gain" ten
extra ciphers between the protocols, which boils down to 18 supported
ciphers on 5209R. On EL6 based systems we end up with 14 supported ciphers
I'll roll up another base-email with this changes and will publish it
within the hour to the YUM repositories.
--
With best regards
Michael Stauber
More information about the Blueonyx
mailing list