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 <=
[email protected]
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 [email protected] T="John,
you have 2 new notifications"
2017-03-30 12:45:37 1ctYWE-0007Fa-AA <=
0100015b1f08efac-ecb7fa47-5a72-4d79-a7ef-c677b0e25a3a-000...@amazonses.com
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-000...@email.amazonses.com
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
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
