[exim] Exim 4.90_1 can't connect securly to a faulty M$ Serv…

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Cyborg
Dátum:  
Címzett: exim-users
Tárgy: [exim] Exim 4.90_1 can't connect securly to a faulty M$ Server

Hi guys,

this comes up now and than...

2019-01-09 20:13:37 1ggu4S-0000di-TI == ***********@kabelmail.de
<***********@kabelmail.de> R=dnslookup T=remote_smtp defer (-37)
H=mx01.xworks.net [31.25.48.11]: TLS session: (SSL_connect):
error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handsha
ke failure

This happens, when you have TLS mandatory for outgoing connections +
forcing modern crypto like this:

remote_smtp:
  driver = smtp
  hosts_require_tls = *
  tls_require_ciphers = HIGH:!TLSv1:!SSLv3:!TLSv1.1
  tls_tempfail_tryclear = false

if you leave out SSL, mails get delivered:

remote_smtp:
  driver = smtp
  hosts_require_tls = *
  tls_require_ciphers = HIGH:!TLSv1:!TLSv1.1
  tls_tempfail_tryclear = false

The mailserver  mx01.xworks.net ( M$ ESMTP afaik ) incorrectly offers
SSLv3 first, and upgrades to TLS 1.2 later :

# openssl s_client -connect 31.25.48.11:25 -starttls smtp
...
SSL handshake has read 5190 bytes and written 513 bytes
Verification: OK
---
New, SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-SHA


O== Conclusion:

it's theire fault, normal implementations force to offer the highest
protcol you speak first.

if you disable the SSLv3 check ( see above ) the send email is delivered
using TLS1.2


2019-01-09 20:26:25 1ggu4S-0000di-TI => ***********@kabelmail.de
<***********@kabelmail.de> R=dnslookup T=remote_smtp H=mx01.xworks.net
[31.25.48.11] X=TLSv1.2:DHE-RSA-AES256-SHA:256 CV=yes C="250 2.0.0
x09JQPvB018254 Message accepted for delivery"
2019-01-09 20:26:25 1ggu4S-0000di-TI Completed

A possible solution, as we all know, they won't fix theire M$ server as
M$ is elite :), would be to check which tls  is used in the end, instead of
dropping the connection first hand at the first sight of trouble.

RFC pls.

best regards,
Marius