Hi,
Some users are reaching out to us telling they have issues connecting
to our service because of incompatibility between the set of ciphers
offered during the connection.
On our send, we decided to use the ciphers suggested by Mozilla on
their SSL Configuration Generator (https://ssl-config.mozilla.org/)
(level "Intermediate") but I'm aware it's more for the HTTPS
connections that ESMTP / TLS.
So maybe there is another set of ciphers recommended for creating
secured connections in email that I'm not aware of. Do you have any
recommendations for this or is the ones from Mozilla (Intermediate)
is good enough?
If you want to avoid loading the link, here are the ciphers suggested
by them:
Ciphers:
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA
-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-P
OLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA
-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
Cipher
suites:
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_S
HA256
And we only accept TLS at v1.2 and higher.
As far as TLS in general is concerned, Mozilla's recommendations are
perfectly sound, and their guidelines are well worth following
regardless of protocol. An excellent baseline, and normally this should
be all you need.
That said, we still decided to deviate from them *only* for SMTP (and
not for i.e. Submission). The reason for this decision comes down to
the number of poorly configured servers out there, and the fact that
TLS in SMTP is still opportunistic. While requiring sane crypto at
Mozilla's level will no doubt weed out a fair bit of spammers,
unfortunately it is (still) likely to also weed out stuff it shouldn't.
And since you won't know before the other side initiates STARTTLS
whether you'll be able to agree on a common handshake, and poor crypto
is still better than no crypto at all (which SMTP generally will
happily allow), this ended up being the compromise.
Regardless of your approach, you should absolutely ensure that ciphers
are used in server-preferred order. This doesn't really matter for
TLSv1.3 since all cipher suites there today are generally considered
equally safe, but it very much does for ciphers in TLSv1.2 (and
anything below).
Should you choose to go down this path, a (possibly limited) variant of
Mozilla's Old level might be appropriate, with only the least insecure
(highest listed) TLSv1.1 and/or TLSv1.0 ciphers allowed. Experiment
until you get no more complaints, rather than adding the whole Old list
of ciphers.
If the other end doesn't support the ciphers at Intermediate level,
they likely don't support TLSv1.2 at all, so in my experience[1] this
is a bit of an either or. If you do want to "fix" this it will have to
be a compromise, but together with the aforementioned server-preferred
order, this should ensure only the worst servers get these worst
ciphers and TLS versions, while everyone else still get the most modern
and safe crypto available to them.
YMMV, and I'm sure some will want to argue that what I'm describing
should never be allowed, but not everyone will have the luxury of being
in a position to discard incoming ham "just" because the sender's
server isn't set up properly. So to be clear, I am not recommending
this course of action, only saying that, based on what you're saying,
this is likely to be the necessary compromise to get around the issue.
[1] Yes, there is the theoretical possibility of a sending server
supporting TLSv1.2 but only with weak ciphers. Feel free to experiment
with that instead, should that be preferable.
--
Christer Mjellem Strand
System Administrator
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
