On 2022-01-10 at 19:15:46 UTC-0500 (Mon, 10 Jan 2022 19:15:46 -0500)
Alex <mysqlstud...@gmail.com>
is rumored to have said:
[...]
Here are my current settings:
# postconf -n -c /etc/postfix-117|grep -E 'tls|cipher'
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_security_level = may
This means that you will use plaintext for sending to many sites,
rather
than falling back to the almost universally supported TLSv1.0 on
sites
that can't do 1.2 or 1.3.
The vulnerabilities I am aware of that justify sticking to v1.2/3 in
web, IMAP, and database servers are not viable against SMTP because
of
the brief, non-repetitive, and largely unpredictable nature of the
TLS
sessions used by SMTP.
Would you explain what specifically about the above that's removed any
ability for clients to build an encrypted connection and require
cleartext?
Is it the exclusion of the use of any TLS version above 1.2?
Typo? s/above/below/
By including '!TLSv1,!TLSv1.1' in the protocol list, you've eliminated
the only TLS versions known to some older systems.
Maybe the part I'm not understanding is whether it's possible to
somehow compromise the server if we offer older versions of TLS?
No, at least not BECAUSE of offering older versions of TLS. There's
nothing inherent to any SSL/TLS protocol version that could make a
server itself vulnerable.
The vulnerabilities which justify deprecation of older versions of TLS
(as well as SSL) and of many cipher variants supported in those older
versions are info leak and connection stability attacks.
What
is my exposure for allowing older versions of TLS?
Nothing widely known that isn't mitigated in current TLS
implementations.
TLS v1.0 can be vulnerable to the BEAST (Browser Exploit Against
SSL/TLS) attack, which requires a man-in-the-middle, a means of
injecting arbitrary data into what the browser sends to the server (e.g.
a malicious Java applet or JavaScript script with a vulnerable browser,)
and a server that will tolerate a bunch of nonsense input without
kicking out the client.
TLS v1.1 vulnerabilities I am aware of are implementation and/or
configuration-specific and require similar special circumstances that
don't apply in SMTP over TLS, such as error-tolerant long-lived
sessions.
There is also a hypothetical risk that because of the deprecation of
older protocol versions, there are vulnerabilities that have not been
publicized and have survived because of the reduced visibility and
significance of those older versions. These would be "unknown unknowns"
that are unknown because too few smart eyes are looking at obsolete
protocols.
The biggest concrete problem with allowing TLSv1.0 and v1.1 is that it
makes you LOOK like low-hanging fruit. It's a marker for systems that do
not conform to simplistic security norms. Such systems come in two
flavors, but the vast majority of non-conforming systems are just
neglected and hence more likely to also have other more easily exploited
problems. The other flavor is systems managed by people who believe that
they are smarter than the average security checklist. Sometimes that
belief is grounded in reality, sometimes not so much.
Very few people have the cryptography chops to usefully evaluate an
extensive list of specific ciphers for maximal safety. 99.9% of such
lists that you will find published are cargo-cult artifacts at some
point, if only when you read the list from RH and drop it in to
Postfix
without deep analysis. If you're going to be like almost everyone and
trust a third party to do such deep analysis, you have to choose your
trusted authorities carefully. Trusting the Postfix developers (and
perhaps the official packagers for your platform) is at least as safe
as
pulling a list from a RH page, and you get the bonus of your
cipherlists
being maintained by SOMEONE ELSE as long as you keep updating
diligently.
Yes, which is exactly why I'm coming here, asking questions, and
trying to understand, instead of just blindly implementing something
from the interwebs.
Yeah, I'm pretty sure you didn't need that lecture, but the people
finding this thread in an archive in 2025 clearly will, because people
have been asking basically the same question forever and getting the
same "use the defaults" answer and it can't hurt to have a searchable
rant on why that's a long-term answer, not just today's judgment of the
defaults.
Just to be clear, here's my current config:
smtpd_tls_security_level = may
smtp_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/cert.pem
smtpd_tls_key_file = /etc/letsencrypt/privkey.pem
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database =
btree:${data_directory}/smtpd_tls_session_cache
tls_random_source = dev:/dev/urandom
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_exclude_ciphers = MD5, RC4, 3DES, IDEA, SEED, aNULL
tls_preempt_cipherlist = yes
smtpd_tls_mandatory_ciphers = high
tls_ssl_options = NO_COMPRESSION, NO_RENEGOTIATION
Nothing is massively problematic there. Possible issues:
1. smtpd_tls_session_cache_database is pointless with modern Postfix and
OpenSSL.
2. The tls_ssl_options settings are probably a historical archive that
originated with attacks that are no longer viable with modern OpenSSL.
Not harmful unless you are desperately bandwidth-limited.
3. smtpd_tls_exclude_ciphers is a mix of overzealous and pointless.
Excluding MD5, RC4, and 3DES explicitly may cause plaintext fallback
with a few oddball clients, IDEA and SEED are not available by default,
aNULL is already applied *when sensible* by Postfix.
Is excluding SSL and TLS for smtpd_tls_protocols above the same as
stipulating >=TLSv1.2 with smtpd_tls_mandatory_protocols?
The answer depends on what exactly you are asking about...
No: smtpd_tls_protocols and smtpd_tls_mandatory_protocols are not
synonyms. They apply in different circumstances. see postconf(5) or the
TLS README file.
Yes: both parameters (and smtp_*_protocols) use the same syntax and
">=TLSv1.2" is functionally equivalent to
"!SSLv2,!SSLv3,!TLSv1,!TLSv1.1" because SSLv1 never existed in public.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
