Viktor,
Thanks for the reply - see in line.
On 3/30/2017 7:10 AM, Viktor Dukhovni wrote:
> On Wed, Mar 29, 2017 at 07:47:57PM +0100, Mike Tubby wrote:
>
>> I have recently installed our COMODO 384-bit ECC PositiveSSL Widlcard
>> Certificate (*.thorcom.net) on relay1|relay2|relay3.thorcom.net and am
>> seeing lots of TLS errors:
>>
>> (SSL_accept): error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
> It is quite possible that many sending systems don't support
> ECDSA/EECDH, and can only do RSA and EDH. In particular for many
> years RedHat disabled ECDSA in their OpenSSL build, and only
> somewhat recently enabled just P-256, P-384 and P-521
>
> https://security.stackexchange.com/questions/65015/is-the-limited-elliptic-curve-support-in-rhel-centos-redhat-openssl-robust-enoug
>
> 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 ;-)
>
>> This appears to suggest that the client is attempting SSLv3 (unless the
>> debug messages are misleading) however I have SSLv3 disabled in Exim config.
> 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
than mislead with SSL3_... when it isn't
But there again the problem doesn't appear to be a lack of shared cipher
either (see below).
>
>> # Comodo ECC new on 17-MAR-2017
>> tls_certificate = /........./thorcom.net-comodo-bundle.crt
>> tls_privatekey = /........./thorcom.net.key
> 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:
https://ssl-tools.net/mailservers/relay2.thorcom.net
(I may have to change this - so it may be different by the time you get
there).
I have TLS v1.0, 1.1 and 1.2 supported, PFS, no Heartbleed, no Poodle,
no weak ciphers, no SSLv2 or SSLv3
There are two valid trust chains (Comodo ECC all the way and an RSA-ECC
bridge for those without the Comodo ECC CA root in their store)
It works perfectly with Google, Amazon, Facebook and most of the other
big internet properties:
2017-03-30 10:18:22 1ctWDk-0006nC-O6 <=
notification+kjdvvd3j7p_i@???
H=69-171-232-130.outmail.facebook.com (mx-out.facebook.com)
[69.171.232.130] P=esmtps X=TLSv1:ECDHE-ECDSA-AES256-SHA:256 CV=no
S=17723 id=ee628b87885c330118a90fb521f61e9b@??? T="John,
you have 2 new notifications"
2017-03-30 12:45:37 1ctYWE-0007Fa-AA <=
0100015b1f08efac-ecb7fa47-5a72-4d79-a7ef-c677b0e25a3a-000000@???
H=a11-64.smtp-out.amazonses.com [54.240.11.64] P=esmtps
X=TLSv1:ECDHE-ECDSA-AES256-SHA:256 CV=no S=7305
id=0100015b1f08efac-ecb7fa47-5a72-4d79-a7ef-c677b0e25a3a-000000@???
T="EE TOC Service Operations Bulletin - Resolved Incident - EEIM891117"
just not Microsoft/Outlook.com:
2017-03-30 12:07:04 TLS error on connection from
mail-oln040092253095.outbound.protection.outlook.com
(APC01-SG2-obe.outbound.protection.outlook.com) [40.92.253.95]
(SSL_accept): error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no
shared cipher
>> # Ciphers: all the EC and GCM first then degrade gracefully
>> tls_require_ciphers = kEECDH+AESGCM:ECDH+AESGCM:DH+AESGCM:RSA+AESGCM:ECDH+AES:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:RC4+MEDIUM:!aNULL:!eNULL:!MD5:!DSS
> 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.
Tried other variants - doesn't fix it.
Even tried 'DEFAULT' - and that doesn't fix it.
checked my selections with:
openssl ciphers '<list of cipher specs>'
to make sure that they are sane - came up with a new "strong but
tolerant" (see below).
Running OopenSSL 1.0.1f on Ubuntu 14.04 LTS
> In particular, this leaves "aNULL" enabled, which might make it
> possible for many of the RedHat systems to negotiate an ADH or
> AECDH ciphersuite. They often run Postfix, which by default supports
> ADH and AECDH ciphersuites for unauthenticated opportunistic TLS.
>
> See https://tools.ietf.org/html/rfc7672#section-8.2
>
> Instead of "!RC4", you might use "+RC4" to allow RC4 as a last
> resort for Windows 2003 Exchange systems, but my impression that
> this is no longer needed, they've almost all been upgraded, and
> you're unlikely to run into one. But do keep an eye out for any
> important correspondents who always end up retrying in cleartext.
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!
>> # disable SSLv2 SSLv3 and compression - force server preference for ciphers
>> openssl_options = -all +no_sslv2 +no_sslv3 +no_compression +cipher_server_preference
> This seems fine, though I don't know whether Exim has a persistent
> server-side TLS context. If not you should also disable session
> tickets with +no_ticket (if supported), but perhaps that's handled
> internally. Do whatever Jeremy or Phil say about that.
>
>> So, is the problem:
>>
>> 1. clients rejecting my ECC 384 bit certificate?
> Well, more likely not supporting more than actively 'rejecting'.
Ok - I suspect that Microsoft systems don't do ECC properly or at all :-(
>> 2. clients persisting in trying SSLv3 when it is, in fact, disabled
> No.
Agreed.
>> 3. brain dead clients unable to use decent modern/strong/PFS ciphers -
>> some of which are mandated in TLSv1.0, v1.1 and v1.2
> See RFC7435 and avoid reducing the security of your MTA by setting
> too high a bar for TLS interoperability. You get more security by
> raising the ceiling, only raise the floor when the excluded features
> are just useless attack surface. Do not disable weaker, but still
> widely "best-available" algorithm combinations.
Read RFC7435 and see what you mean but even turning on all ciphers
doesn't fix my specific problem with Microsoft/Outlook.
I have build a new specification which I call "strong but tolerant":
# strong but tolerant
tls_require_ciphers = AESGCM:AES256:aNULL:-aNULL:HIGH:MEDIUM:!RC4:@STRENGTH
Which gives me this list:
root@relay2:/var/log/exim# openssl ciphers
'AESGCM:AES256:aNULL:-aNULL:HIGH:MEDIUM:!RC4:@STRENGTH' | tr ':' '\n'
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
DHE-DSS-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ECDH-RSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
SRP-DSS-AES-256-CBC-SHA
SRP-RSA-AES-256-CBC-SHA
SRP-AES-256-CBC-SHA
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-SHA256
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
ECDH-RSA-AES256-SHA384
ECDH-ECDSA-AES256-SHA384
ECDH-RSA-AES256-SHA
ECDH-ECDSA-AES256-SHA
AES256-SHA256
AES256-SHA
PSK-AES256-CBC-SHA
ADH-AES256-GCM-SHA384
AECDH-AES256-SHA
ADH-AES256-SHA256
ADH-AES256-SHA
ADH-CAMELLIA256-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-DSS-CAMELLIA256-SHA
CAMELLIA256-SHA
AECDH-DES-CBC3-SHA
ADH-DES-CBC3-SHA
ECDHE-RSA-DES-CBC3-SHA
ECDHE-ECDSA-DES-CBC3-SHA
SRP-DSS-3DES-EDE-CBC-SHA
SRP-RSA-3DES-EDE-CBC-SHA
SRP-3DES-EDE-CBC-SHA
EDH-RSA-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHA
ECDH-RSA-DES-CBC3-SHA
ECDH-ECDSA-DES-CBC3-SHA
DES-CBC3-SHA
PSK-3DES-EDE-CBC-SHA
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
DHE-DSS-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
ECDH-RSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256
AES128-GCM-SHA256
ADH-AES128-GCM-SHA256
AECDH-AES128-SHA
ADH-AES128-SHA256
ADH-AES128-SHA
ADH-CAMELLIA128-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA
SRP-DSS-AES-128-CBC-SHA
SRP-RSA-AES-128-CBC-SHA
SRP-AES-128-CBC-SHA
DHE-RSA-AES128-SHA256
DHE-DSS-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
DHE-RSA-CAMELLIA128-SHA
DHE-DSS-CAMELLIA128-SHA
ECDH-RSA-AES128-SHA256
ECDH-ECDSA-AES128-SHA256
ECDH-RSA-AES128-SHA
ECDH-ECDSA-AES128-SHA
AES128-SHA256
AES128-SHA
CAMELLIA128-SHA
PSK-AES128-CBC-SHA
ADH-SEED-SHA
DHE-RSA-SEED-SHA
DHE-DSS-SEED-SHA
SEED-SHA
root@relay2:/var/log/exim#
So there really should be "something for everybody" in there ;-)
I think I'm going to have to go and buy a plain RSA2048/SHA256 cert from
RapidSSL or Comodo for one host (relay1.thorcom.net) and see if the
problem goes away :-(
Mike
