On Tue, Nov 28, 2017 at 09:27:49PM +0200, Nikolaos Milas wrote:
> Nov 28 12:55:43 vmail2 postfix/smtp[782]: SSL_connect error to
> rcs12.rc.auth.gr[155.207.51.12]:25: lost connection
> Nov 28 12:55:43 vmail2 postfix/smtp[782]: 4623A80004F2F: Cannot start TLS:
> handshake failure
> Nov 28 12:55:43 vmail2 postfix/smtp[782]: SSL_connect error to
> rcs13.rc.auth.gr[155.207.144.13]:25: lost connection
> Nov 28 12:55:43 vmail2 postfix/smtp[782]: 4623A80004F2F: Cannot start TLS:
> handshake failure
> Nov 28 12:55:44 vmail2 postfix/smtp[782]: 4623A80004F2F: host
> mailsrv1.ccf.auth.gr[155.207.1.1] said: 450 4.7.1 try again later (in reply
> to DATA command)
> Nov 28 12:55:45 vmail2 postfix/smtp[782]: 4623A80004F2F:
> to=<rescomc...@rc.auth.gr>, relay=mailsrv2.ccf.auth.gr[155.207.1.2]:25,
> delay=2.4, delays=0.096/0.001/1.8/0.52, dsn=4.7.1, status=deferred (host
> mailsrv2.ccf.auth.gr[155.207.1.2]
> said: 450 4.7.1 try again later (in reply to DATA command))
>...
> Nov 28 13:01:22 vmail2 postfix/smtp[782]: SSL_connect error to
> rcs12.rc.auth.gr[155.207.51.12]:25: lost connection
> Nov 28 13:01:22 vmail2 postfix/smtp[782]: 4623A80004F2F: Cannot start TLS:
> handshake failure
> Nov 28 13:01:22 vmail2 postfix/smtp[782]: 4623A80004F2F:
> to=<rescomc...@rc.auth.gr>, relay=rcs12.rc.auth.gr[155.207.51.12]:25,
> delay=340, delays=339/0.002/0.15/0.35, dsn=2.6.0, status=sent (250 2.6.0
> <20171128105543.4623a80004...@vmail2.noa.gr> Queued mail for delivery)
This is expected. The first two MX hosts are ancient Microsoft
Exchange servers, probably on Windows 2003, where the TLS stack
is rather crippled. Their only working TLS ciphersuite is RC4,
and they only see the first 64 ciphersuites in the TLS HELLO.
The third uses greylisting to force a later retry.
$ dig +short -t mx rc.auth.gr | sort -n | awk '{print $NF}' | sed 's/\.$//'
rcs12.rc.auth.gr
rcs13.rc.auth.gr
mailsrv1.ccf.auth.gr
mailsrv2.ccf.auth.gr
$ for mx in $(dig +short -t mx rc.auth.gr | sort -n | awk '{print $NF}' |
sed 's/\.$//')
do
posttls-finger -c -Lsummary,ssl-debug "[$mx]"; echo
done
posttls-finger: SSL_connect:before/connect initialization
posttls-finger: SSL_connect:SSLv2/v3 write client hello A
posttls-finger: SSL_connect error to rcs12.rc.auth.gr[155.207.51.12]:25:
lost connection
posttls-finger: SSL_connect:before/connect initialization
posttls-finger: SSL_connect:SSLv2/v3 write client hello A
posttls-finger: SSL_connect error to rcs13.rc.auth.gr[155.207.144.13]:25:
lost connection
posttls-finger: SSL_connect:before/connect initialization
...
posttls-finger: Untrusted TLS connection established to
mailsrv1.ccf.auth.gr[155.207.1.1]:25: TLSv1.2 with cipher AES256-GCM-SHA384
(256/256 bits)
posttls-finger: SSL_connect:before/connect initialization
...
posttls-finger: Untrusted TLS connection established to
mailsrv2.ccf.auth.gr[155.207.1.2]:25: TLSv1.2 with cipher AES256-GCM-SHA384
(256/256 bits)
> On the older server, I didn't see such errors.
If you want to use TLS with these long past their use-by date
Exchange servers, you need to disable a bunch of unnecessary
ciphers that push RC4 out of the first 64 slots:
smtp_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5
With that, you'll be able to complete a TLS handshake even with
the first two MX hosts:
$ for mx in $(dig +short -t mx rc.auth.gr | sort -n | awk '{print $NF}' |
sed 's/\.$//')
do
posttls-finger -o "tls_medium_cipherlist=$(postconf -hd
tls_medium_cipherlist):"'!MD5:!aDSS:!kECDH:!kDH:!SEED:!IDEA:!RC2:!RC5' -c -lmay
-Lsummary "[$mx]"
done
posttls-finger: Untrusted TLS connection established to
rcs12.rc.auth.gr[155.207.51.12]:25: TLSv1 with cipher RC4-SHA (128/128 bits)
posttls-finger: Untrusted TLS connection established to
rcs13.rc.auth.gr[155.207.144.13]:25: TLSv1 with cipher RC4-SHA (128/128 bits)
posttls-finger: Untrusted TLS connection established to
mailsrv1.ccf.auth.gr[155.207.1.1]:25: TLSv1.2 with cipher AES256-GCM-SHA384
(256/256 bits)
posttls-finger: Untrusted TLS connection established to
mailsrv2.ccf.auth.gr[155.207.1.2]:25: TLSv1.2 with cipher AES256-GCM-SHA384
(256/256 bits)
Disabling the above cipher classes is harmless, they should not be
needed in practice. This is only needed for TLS with an increasingly
rare set of peer servers, those still stuck running long unsupported
14-year old Windows software. With a bit of luck these will be
replaced some day soon, they probably have multiple unpatched security
issues.
--
Viktor.
