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. 

-- 
    Viktor.

Reply via email to