Troubleshooting SSL/TLS version on SMTP / Outmail service

[Code Crafters]

If there is a way to be more flexible using OpenSSL then we will certainly look into that. Obviously this would help a lot. We will also see if the logging can be more comprehensive but I'm not sure if we get any details back from OpenSSL as to why the handshake fails, only that it does fail.

[EKjellquist]

Any chance of upping the available key exchanges for a future release of the built-in web server in AMS? Currently Chrome's security inspect tab reads:

The connection to this site uses a strong protocol (TLS 1.2), an obsolete key exchange (RSA), and a strong cipher (AES_128_GCM).

This is the default connecting directly to AMS (Webmail using TLS 1.2); when I proxy through Apache 2.4.25 / OpenSSL 1.0.2k:

The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA with P-256), and a strong cipher (AES_256_GCM).

Defaulting to the stronger keys / ciphers does increase computational overhead / connect time, so having a bit of control over that is probably a good idea if the newer Diffee-Hellman / Elliptical Curve keys were added. Since you guys do already update AMS/AFS when new OpenSSL versions come out, would it be possible to include options for webmail (possibly for the other services also) to be able to control which keys / ciphers the server will use and possibly to enforce the order of selection server-side (as Apache does)?

[Code Crafters]

If we can use 256-bit AES encryption instead of 128-bit then that would likely become the default. We may include an option for the less secure cipher but I'm not sure anyone would generally want this unless there were compatibility issues. We would look to do this across all services.

[EKjellquist]

I'm not sure how it would affect non-http email services / handshakes exactly; Apache does give you options to accept various levels of SSL/TLS versions you can accept concurrently (with the ability to securely downgrade the connection if, say, you're using TLS 1.2 but someone wants to connect via 1.1 or 1.0), as well as either explicitly specifying the ciphers the server uses (or just more general categories of 'High' 'Medium' etc). The current ciphers with stronger generally-accepted key exchanges use DHE with Elliptical Curves (ECDHE) which are all currently strong with TLS 1.2:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256

OpenSSL is planning their 1.1.1 release April 5th to support TLS 1.3 (https://www.thesslstore.com/blog/openss ... 3-april-5/); obvs most devs are going to require some time to build the protocol into their releases so it'll be awhile before it's commonplace, but I was hoping we could get at least the ECDHE ciphers as AMS/AFS options...

[Code Crafters]

OpenSSL 1.1.x is a new beta release which has different code libraries to replace the old ones. It also discontinues SSL v2 and v3. When it's officially released we will consider adding it at the right time. We don't recommend using SSL v2/3 but some users still want this compatibility for older clients. We will eventually discontinue SSL version support in favour of TLS v1.0 and later versions only.