On 2022-01-10 at 11:08:49 UTC-0500 (Mon, 10 Jan 2022 11:08:49 -0500)
Alex <mysqlstud...@gmail.com>
is rumored to have said:
Hi,
I have a postfix-3.5.10 system and having a little trouble configuring
it to ensure I'm not including any vulnerable ciphers. I had
previously posted about this issue in September, and thought I
followed the instructions I was given, but a recent security scan
(onsecurity) shows port 25 is still vulnerable to the SWEET32 attack.
But it actually isn't. Sweet32 can only be used against very long-lived
TLS sessions using obsolete ciphers. You have to do some hacking on
OpenSSL code to get it to support a vulnerable cipher in recent
versions.
Fire that vendor, they lie to you.
For reference to previously discussion:
https://www.mail-archive.com/postfix-users@postfix.org/msg92857.html
This system is just a general smtp/submission/pop/imap box with no
mandatory crypto/certificate requirements. We also don't need to
maintain compatibility with legacy systems.
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.
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/cert.pem
smtpd_tls_exclude_ciphers = MD5, RC4, 3DES, IDEA, SEED
smtpd_tls_key_file = /etc/letsencrypt/privkey.pem
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
This means you will force many sites to fallback to plaintext to send
you mail. Or just never be able to send you mail, because some sites
will only send with TLS even though they can't do modern TLS. Sturgeon's
Law applies to mail admins...
smtpd_tls_session_cache_database =
btree:${data_directory}/smtpd_tls_session_cache
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
tls_ssl_options = NO_COMPRESSION, NO_RENEGOTIATION
What am I missing? Is this redhat.com article accurate?
https://access.redhat.com/articles/1468593
It probably was not terrible when written, for the RedHat-patched
version of Postfix 2.10. It was last updated 3 years ago.
I believe I was told that trying to explicitly define the cipher list
was a bad idea.
It is, unless you have reason to believe that someone advising you
otherwise is wiser about Internet security than Wietse and Viktor in
consultation with each other and a large community of Postfix users. Or
if you have well-defined special needs like FIPS adherence or other
arbitrary cipher prohibitions.
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.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
