Re: [exim] SSL3_GET_CLIENT_HELLO No shared cipher - when SSL…

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Viktor Dukhovni
Date:  
À: exim-users
Sujet: Re: [exim] SSL3_GET_CLIENT_HELLO No shared cipher - when SSLv3 disabled?
On Thu, Mar 30, 2017 at 01:09:48PM +0100, Michael J. Tubby B.Sc. MIET wrote:

> > RedHat customers tend to like stability, and tend to run supported,
> > but quite old releases. So ECDSA-only (with no RSA) is likely to
> > run into friction. I don't recall whether Exim supports configuring
> > two simultaneous certificate chains, one RSA and one ECDSA, but that
> > may be needed to avoid interoperability issues with some systems.
>
> There were issues with patent claims and allegedly weakened curves - which
> is why we always choose secp384r1 curve ;-)


Yes, but for a long time RedHat's OpenSSL was neutered to not
support EC, not even P-256, P-384 or P-521. These were only
"recently" added.

> > The debug messages are misleading. SSL3 here is the shared code
> > that supports the entire SSLv3/TLS1.[012] family of protocols.
>
> Misleading debug messages are the bain of my life! It would be much nicer
> to say:
>
>     TLS_GET_CLIENT_HELLO: vers=TLSv1.1 - No shared cipher


The error stack in OpenSSL holds pointers to static error tables,
any additional context comes from the application, but with the
handshake aborted, there never was an agreed TLS protocol version.

> > Just ECDSA may not be ready for prime-time.
>
> My ECC is ready for prime time - it checks out fine on ssl-tools.net and
> other sites - thus:


What I was trying to say is that the (SMTP) world at large is not
yet ready for ECC-only servers. Yes, your server is ready, but
interoperability difficulties are to be expected.

> It works perfectly with Google, Amazon, Facebook ...


Bleeding edge is fine.

> just not Microsoft/Outlook.com:


And likely a long tail of other late-to-deploy systems.

> > SMTP is not HTTPS, see RFC7435, you get more security by being
> > reasonably tolerant of less-capable peers. This cipherlist is
> > much too strict. Instead, use:
> >
> >      aNULL:-aNULL:HIGH:MEDIUM:!RC4:!kECDH:!kDH:@STRENGTH

>
> Tried that - doesn't fix it.


It fixes Postfix systems on RedHat that support anonDH, but not
ECDSA. It does not fix Microsoft, since they don't support anonDH
either. Mind you, they do support ECDHE, so one might think that
they could also handle ECDSA.

    posttls-finger: Untrusted TLS connection established to
    nist-gov.mail.protection.outlook.com[207.46.163.215]:25:
    TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)


> Running OopenSSL 1.0.1f on Ubuntu 14.04 LTS


I sure hope that Canonical have backported all relevant OpenSSL
security updates. The OpenSSL 1.0.1 branch reached End-Of-Life a
few months back in December 2016. You'll get more security by
switching to 1.0.2 than anything you'll get from stronger ciphers,
fancier certificate algorithms, ...' That might mean an upgrade
to 16.04 LTS.

> The problem here is that I advertise STARTTLS to all hosts, Microsoft
> (outlook.com) connects, generated the error and disconnects. They don't
> come back and try in clear text!


That's unfortunate, but it is just one of a number of suboptimal
behaviours exhibited by the outlook.com SMTP servers.

-- 
    Viktor.