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.