On Fri, Oct 29, 2021 at 08:36:38PM -0700, Dan Mahoney (Gushi) wrote:
> I see sites like cipherlist.eu suggesting overriding the "medium" cipher
> set to only be:
Ignore much of their misguided advice..
> smtpd_use_tls = yes
> smtpd_tls_security_level = may
These are fine.
> smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
Leave TLSv1 and TLSv1.1 enabled, there's no compelling reason to turn
these off for opportunistic TLS.
> smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
Plausibly OK on submission ports where TLS is mandatory, and clients are
*your* users.
> smtpd_tls_mandatory_ciphers = medium
> tls_medium_cipherlist = EECDH+AESGCM:EDH+AESGCM
This combination is silly. They call it "medium", but redefine "medium"
to high. For submission just set the cipher grade to "high". There's
no need to force AESGCM in SMTP.
> tls_preempt_cipherlist = yes
This is sensible, unless you have a large population of submission
clients on Android phones where CHACHA20 is more power-efficient.
> WHich feels like it would break anyone with an older mail server.
Less of an issue on the submission ports (mandatory TLS), but yes,
security happens when you raise the ceiling, raising the floor is
just as likely to be counter-productive, and needs to be well
thought out and well timed (when the high ceiling is a predominant
norm, and essentially nobody is still using the dated crypto).
> We *want* to receive mail from everyone -- since we're saying "may" we
> basically default to no cipher if we can't do one. If someone else
> thinks ECDHE-RSA-AES128-GCM-SHA256 is enough, I'd rather that be used
> than go plaintext.
Right idea, though of course the example you give is supported by the
overly strict misguided recommendations.
> It also feels like overriding "medium" is a really poor idea here.
> Like, if you want optimal security, why wouldn't you override high?
Correct.
> When I look at postconf -d, I see:
>
> tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH
> tls_medium_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH
> tls_low_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:+RC4:@STRENGTH
> tls_export_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH
The export and low ciphers are no longer supported by OpenSSL (1.1.x and
3.0.0), the parameters are dead code, but no need to remove them, just
annoys users with warnings.
> But can't find how @STRENGTH is evaluated.
Just a stable sort on the symmetric bulk cipher key size (AES256
comes out ahead of AES128).
> 1) What does @STRENGTH mean in this context? Where is it defined? It is
> some kind of bitstrength equivalence?
See above. Ensures the symmetric bulk ciphers with longer keys have
priority.
> 2) Will postfix allow you to specify a "custom" cipherlist while leaving
> the defaults in, like tls_ourorg_cipherlist?
No, but you can choose a cipher that has all the ciphers you need and
then specify a few carefully selected exclusions to narrow it down,
but modifying the cipher grade definitions but by using the
"exclude" parameters:
smtp_tls_exclude_ciphers = ...
smtp_tls_mandatory_exclude_ciphers = ...
smtpd_tls_exclude_ciphers = ...
smtpd_tls_mandatory_exclude_ciphers ...
If your OpenSSL is recent enough, this is not necessary, but it is
OK to disable the below, which are obsolete:
smtp_tls_exclude_ciphers = 3DES, MD5, IDEA, SEED, kDH, kECDH
smtpd_tls_exclude_ciphers = 3DES, MD5, IDEA, SEED, kDH, kECDH
> 3) Will the builtin values of these ciphers change over time, for
> example to exclude known-broken or known-deprecated ciphers, inline with
> RFC's perhaps? (i.e. will "High" change)
Mostly through changes in OpenSSL, Postfix does not need to be the
gatekeeper. I could be persuaded to disable some of the outdated
algorithms, just in case some user is still building Postfix against
OpenSSL 1.0.2, but they'd be getting illusory security, 1.0.2 has
been EOL for ~2 years IIRC.
Some time back I've raised the default compiled-in DHE group to 2048
bits, and switched ECDHE to "auto" curve negotiation. With OpenSSL 3.0
and Postfix 3.7 you'll also get "auto" DHE group selection. Postfix
has robust support for session tickets, ...
I strive for broad interoperability without too much historical baggage.
See <https://datatracker.ietf.org/doc/html/rfc7435>.
> 4) Is there an equivalent target for tls_protocols, i.e that only
> reprents "high" (as in non-broken) protocols? For example, it looks
> like at some point postfix stopped doing sslv2 and sslv3 (so the above
> smtpd_tls_protocols is already wrong for a modern postfix?), but with
> tls10 also known-problematic, will that drop out at some point?
I am not aware of any substantive issues with TLS 1.0 in SMTP that
would suggest it is important to disable it in opportunistic TLS.
With mandatory TLS (submission on servers, and DANE or perhaps "secure"
via policy tables on clients), it can make sense to set the floor
higher, though my DANE survey still shows a handful of MX hosts (out of
a total of ~14300 distinct MX host names) with TLSA records that only
support TLS 1.0:
xt.digsys.bg
klipstein.com.br
mailserver.melhorvoo.com.br
mail.czfruit.cz
mail.vrbata.cz
mail.rotor.eu
castle.8p8c.net
postbox.8p8c.net
smtp.aeon-hq.net
Most likely your users are not sending any mail to these, but *someone*
probably is, and not experiencing any harm...
--
Viktor.
