On 2022-01-11 at 10:16:20 UTC-0500 (Tue, 11 Jan 2022 16:16:20 +0100)
Charlotte 🦝 Delenk <lo...@chir.rs>
is rumored to have said:
On 11.01.22 15:46, Bill Cole wrote:
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.
That really seems like a problem with these ancient systems. openssl
added TLS 1.2 support 9 years ago, and 6 years ago the last version to
not support TLS 1.2 (1.0.0) had its support ended.
I absoutely agree in principle.
Not all mail systems use OpenSSL. Not all mail systems run on Unix-like
platforms. The issue is particularly acute with embedded SMTP clients in
devices that are not general-pupose computers. (e.g. network gear,
storage systems, refrigerators, etc.)
RHEL 5, discontinued in 2020, was the last version of RHEL to ship
with openssl 1.0.0.
And it's still the basis of specialized distributions lurking under the
hood of "obsolete" commercial products that people keep running until
they break, long past support has ended. XenServer comes to mind.
In the Windows world, Windows Server 2008 has been supporting TLS 1.2
since 2017. Standard and Expanded support for it ended in 2015 and
2020 respectively.
If you say so...
I can't retain enough detail on Windows hilarity to be certain, but as I
recall, there are problems that are specific to certain versions of
Exchange on certain versions of Windows which make it necessary for
peers to enable older protocols and/or ciphers.
We are talking about systems that should not be running in prod
anymore, but still are due to inertia.
Yes, we are. Also, misconfigured systems that were inadvertantly told to
do TLSv1 a decade ago (or maybe last week...) in a way that prevented
them from doing better.
Mails not being delivered may hopefully be the push that kickstarts
upgrading efforts.
One can certainly hope that. One should be prepared to have such hopes
disappointed on a regular basis. Beyond that, I don't think we're even
talking about rejection of mail, but failure to negotiate encryption at
transport time. That has even less of a push, because you have to do log
analysis to notice it.
And I should adjust my advice slightly: it is likely to be less harmful
to limit Postfix's client-side (smtp_*) TLS settings than to constrict
what smtpd will accept for transport security from remote servers. It
is also certainly safer to demand 1.2 now than it was last year, but the
risk of wanting to interoperate with a system that won't do better than
1.0 is still real.
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.
Regardless of whether or not there are exploitable security issues in
the protocol itself, TLS support is a somewhat good indication of how
up-to-date the client is.
Note that smtp_tls_* parameters must be compatible with unknowable SMTP
*servers* to which you offer mail.
Clients not supporting TLS 1.2 have likely not been receiving security
updates for over a year at this point (see above), making it more
likely for them to be vulnerable to critical security vulnerabilities.
Yes. That's not my problem as a mail admin. It's not enough to make me
say that I don't want their legitimate mail to be transferred with the
best encryption that they CAN do. It's even less my problem when I'm
passing along mail to a receiving server that my system may have never
contacted before and may never contact again.
The bottom line with opportunistic TLS is that rejecting any specific
flavor of encryption can result in falling back to plaintext for some
partners that could otherwise use that form of encryption. Unless a
protocol is actively dangerous to give access to your private key (e.g.
SSLv2) or a cipher is so weak that anyone can crack it (e.g. 56-bit DES)
you should consider allowing it. I'd even consider allowing DES or SSLv3
if they were demanded by a customer, because they are at least a little
better than nothing. (SSLv2 isn't.)
It's mildly amusing that THIS THREAD is an example of one risk of not
simply trusting Wietse & Viktor (with broad community oversight) to get
the TLS defaults right. In-depth contemplation and discussion of all
these details can be a massive time-sink, and if you go with a bespoke
configuration you will need to reconsider your choices on a regular
basis as vulnerabilities are discovered and new versions of TLS are
defined.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
