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.
> 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.
> # 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.
> # 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
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.
> # 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'.
> 2. clients persisting in trying SSLv3 when it is, in fact, disabled
No.
> 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.
--
Viktor.
