Bug #7576
closedCertificates and SSL config for SMTP (25) needs review
0%
Description
Nessus info: TLS Version 1.0 Protocol Detection¶
Synopsis¶
The remote service encrypts traffic using an older version of TLS.
Description¶
The remote service accepts connections encrypted using TLS 1.0. TLS 1.0 has a number of cryptographic design flaws. Modern implementations of TLS 1.0 mitigate these problems, but newer versions of TLS like 1.2 and 1.3 are designed against these flaws and should be used whenever possible.
As of March 31, 2020, Endpoints that aren’t enabled for TLS 1.2 and higher will no longer function properly with major web browsers and major vendors.
PCI DSS v3.2 requires that TLS 1.0 be disabled entirely by June 30, 2018, except for POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits.
Links¶
https://www.tenable.com/plugins/nessus/104743
https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-00
Nessus info: SSL Anonymous Cipher Suites Supported¶
Synopsis¶
The remote service supports the use of anonymous SSL ciphers.
Description¶
The remote host supports the use of anonymous SSL ciphers. While this enables an administrator to set up a service that encrypts traffic without having to generate and configure SSL certificates, it offers no way to verify the remote host's identity and renders the service vulnerable to a man-in-the-middle attack.
Note: This is considerably easier to exploit if the attacker is on the same physical network.
Links¶
https://www.securityfocus.com/bid/28482
https://cvedetails.com/cve/CVE-2007-1858
https://www.tenable.com/plugins/nessus/31705
http://www.nessus.org/u?3a040ada
Nessus: SSL Certificate Cannot Be Trusted¶
Synopsis¶
The SSL certificate for this service cannot be trusted.
Description¶
The server's X.509 certificate cannot be trusted. This situation can occur in three different ways, in which the chain of trust can be broken, as stated below :
- First, the top of the certificate chain sent by the server might not be descended from a known public certificate authority. This can occur either when the top of the chain is an unrecognized, self-signed certificate, or when intermediate certificates are missing that would connect the top of the certificate chain to a known public certificate authority.
- Second, the certificate chain may contain a certificate that is not valid at the time of the scan. This can occur either when the scan occurs before one of the certificate's 'notBefore' dates, or after one of the certificate's 'notAfter' dates.
- Third, the certificate chain may contain a signature that either didn't match the certificate's information or could not be verified. Bad signatures can be fixed by getting the certificate with the bad signature to be re-signed by its issuer. Signatures that could not be verified are the result of the certificate's issuer using a signing algorithm that Nessus either does not support or does not recognize.
If the remote host is a public host in production, any break in the chain makes it more difficult for users to verify the authenticity and identity of the web server. This could make it easier to carry out man-in-the-middle attacks against the remote host.
Links¶
https://www.tenable.com/plugins/nessus/51192
https://en.wikipedia.org/wiki/X.509
https://www.itu.int/rec/T-REC-X.509/en
Nessus: SSL Self-Signed Certificate¶
Synopsis¶
The SSL certificate chain for this service ends in an unrecognized self-signed certificate.
Description¶
The X.509 certificate chain for this service is not signed by a recognized certificate authority. If the remote host is a public host in production, this nullifies the use of SSL as anyone could establish a man-in-the-middle attack against the remote host.
Note that this plugin does not check for certificate chains that end in a certificate that is not self-signed, but is signed by an unrecognized certificate authority.
Links¶
Updated by Pavel Kácha over 2 years ago
- Status changed from New to In Review
In my opinion Mentat servers have NO reason to accept any mail from outside world (change my mind ). I have disabled smtpd listening on inet:25 in master.cf, let's see if something breaks.
Updated by Pavel Kácha over 2 years ago
Pavel Kácha wrote in #note-2:
In my opinion Mentat servers have NO reason to accept any mail from outside world (change my mind ). I have disabled smtpd listening on inet:25 in master.cf, let's see if something breaks.
Sooooo... seems Mentat needs SMTP (even though is seems it should use sendmail by default at mailer.py). Reconfigured postfix to actually run smtpd and listen on localhost, seems to work.