Thank you, guys. I appreciate it. Have a great day.
On 07/01/2023 9:23 PM, Viktor Dukhovni wrote:
On Sat, Jan 07, 2023 at 12:38:06PM +0400, Sam wrote:
when I run `nmap --script vuln example.com` against a server I manage, I
get the following vulnerability on my server on both ports 465 and 587.
The only solutions I found are for legacy systems.
The "nmap" report is wasting your time. Support for anon-DH in
*servers* is not a feature, not a bug. If the *client* actually
authenticates the server, the *client* will not support anon-DH ciphers,
and they will not be negotiated. If the client does not authenticate
the server, pretending that hiding anon-DH ciphers creates
authentication is magical thinking.
https://www.rfc-editor.org/rfc/rfc7672#section-8.2
| State: VULNERABLE
| Transport Layer Security (TLS) services that use anonymous
| Diffie-Hellman key exchange only provide protection against passive
| eavesdropping, and are vulnerable to active man-in-the-middle attacks
| which could completely compromise the confidentiality and integrity
| of any data exchanged over the resulting session.
The server is NOT vulnerable. *Clients* that don't authenticate the server
are vulnerable to MITM, whether or not anon-DH ciphers are negotiated.
Ignore overzealous security scan reports. They are trying to look more
thorough by finding as much as possible, whether a real issue or not.
On Sat, Jan 07, 2023 at 06:53:38PM +0400, Sam wrote:
Thank you for explaining. I'm sorry I'm not sure whether I understand
that there's a solution or it's OK. Is there a setting that I can update
in postfix to fix this? I already limited smtpd ciphers to high, with
smtpd_tls_ciphers.
Is there something I can do to fix this "vulnerability"?
Do nothing. Your server is fine.
On Sat, Jan 07, 2023 at 05:26:57PM +0100, Matus UHLAR - fantomas wrote:
use smtpd_tls_mandatory_exclude_ciphers instead of smtpd_tls_exclude_ciphers
for ports 465/587 as *_mandatory_* options apply on ports where tls is
mandatory
Nothing needs to be done.
http://www.postfix.org/TLS_README.html#client_tls_limits
...
Consequently, TLS security for mail delivery to public MX hosts is
almost entirely the client's responsibility. The server is largely
a passive enabler of TLS security, the rest is up to the client.
While the server has a greater opportunity to mandate client
security policy when it is a dedicated MSA that only handles
outbound mail from trusted clients, below we focus on the client
security policy.
