Mailing List Archive

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 == ***********
<***********> R=dnslookup T=remote_smtp defer (-37) []: 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:

  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:

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

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

# openssl s_client -connect -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
    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 => ***********
<***********> R=dnslookup T=remote_smtp
[] 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,

## List details at
## Exim details at
## Please use the Wiki with this list -