Some issues with SSL security and POP3/IMAP
Hi.
When check my servers (update with 70.0.34) get some issues:
Some idea for correct this?
- Cipher incorrect
- Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), potential DoS threat
- SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers
- BEAST (CVE-2011-3389) TLS1: ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA DHE-RSA-CAMELLIA256-SHA AES256-SHA CAMELLIA256-SHA ECDHE-RSA-AES128-SHA DHE-RSA-AES128-SHA DHE-RSA-CAMELLIA128-SHA AES128-SHA CAMELLIA128-SHA DES-CBC3-SHA VULNERABLE -- but also supports higher protocols TLSv1.1 TLSv1.2 (likely mitigated)
- LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches
Testing server preferences
Has server cipher order? nope (NOT ok)
Negotiated protocol TLSv1.2
Negotiated cipher ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) (limited sense as client will pick)
Negotiated cipher per proto (limited sense as client will pick)
ECDHE-RSA-AES256-SHA: TLSv1, TLSv1.1
ECDHE-RSA-AES256-GCM-SHA384: TLSv1.2
No further cipher order check has been done as order is determined by the client
Testing server defaults (Server Hello)
TLS extensions (standard) "renegotiation info/#65281" "EC point formats/#11" "session ticket/#35" "heartbeat/#15"
Session Ticket RFC 5077 hint 300 seconds, session tickets keys seems to be rotated < daily
SSL Session ID support yes
Session Resumption Tickets: yes, ID: yes
TLS clock skew Random values, no fingerprinting possible
Signature Algorithm SHA256 with RSA
Server key size RSA 2048 bits
Server key usage Digital Signature, Key Encipherment
Server extended key usage TLS Web Server Authentication, TLS Web Client Authentication
Serial / Fingerprints 068CC887A23D555336882766B2219BDD / SHA1 560F1784F243C938EFDFD804CAB1639C999A6B58
SHA256 A14F1C0A6DCE88245896C93D365769AF3A481009965655301206D94AFFDC706A
Common Name (CN) hq.example.net
subjectAltName (SAN) hq.example.net www.hq.example.net
Issuer cPanel, Inc. Certification Authority (cPanel, Inc. from US)
Trust (hostname) certificate does not match supplied URI
Chain of trust Ok
EV cert (experimental) no
Certificate Validity (UTC) 354 >= 60 days (2018-04-30 02:00 --> 2019-05-01 01:59)
# of certificates provided 3
Certificate Revocation List http://crl.comodoca.com/cPanelIncCertificationAuthority.crl
OCSP URI http://ocsp.comodoca.com
OCSP stapling not offered
OCSP must staple extension --
DNS CAA RR (experimental) not offered
Certificate Transparency yes (certificate extension)
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), timed out
CCS (CVE-2014-0224) not vulnerable (OK)
ROBOT not vulnerable (OK)
Secure Renegotiation (CVE-2009-3555) not vulnerable (OK)
Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), potential DoS threat
CRIME, TLS (CVE-2012-4929) not vulnerable (OK) (not using HTTP anyway)
POODLE, SSL (CVE-2014-3566) not vulnerable (OK)
TLS_FALLBACK_SCSV (RFC 7507) Downgrade attack prevention supported (OK)
SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
make sure you don't use this certificate elsewhere with SSLv2 enabled services
https://censys.io/ipv4?q=A14F1C0A6DCE88245896C93D365769AF3A481009965655301206D94AFFDC706A could help you to find out
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no common primes detected
BEAST (CVE-2011-3389) TLS1: ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA DHE-RSA-CAMELLIA256-SHA AES256-SHA CAMELLIA256-SHA
ECDHE-RSA-AES128-SHA DHE-RSA-AES128-SHA DHE-RSA-CAMELLIA128-SHA AES128-SHA CAMELLIA128-SHA
DES-CBC3-SHA
VULNERABLE -- but also supports higher protocols TLSv1.1 TLSv1.2 (likely mitigated)
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches
RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK)Some idea for correct this?
-
Hi @speckados What are you using to test with? Are your settings default? Thanks! 0 -
github.com/drwetter/testssl.sh Example test: ./testssl.sh -t pop3 castris.commail.server.com:110
I'm using defaults setup on incoming mail server Best regards0 -
Hello, Did you ever figure out how to address the "LUCKY13 (CVE-2013-0169)" issue? I'm seeing this with similar scan on port 21 Pure FTP. - Mike 0 -
Hi @JIKOmetrix You should be able to see if you have the patch for this in your version of OpenSSL by running the following: [root@cent6 ~]# rpm -q --changelog openssl |grep CVE-2013-0169 - fix for CVE-2013-0169 - SSL/TLS CBC timing attack (#907589)
You should be able to show the above to your PCI compliance organization as proof it's been patched. This is relevant only for CentOS 6 and my assumption is if you're getting this you're on CentOS 6 as this doesn't appear to affect the OpenSSL version on CentOS 7 servers.0 -
Hello, I'm on CentOS7.6 and OpenSSL 1.0.2k-fips 26 Jan 2017. I performed the command and received no output. [root@host76 ~]# rpm -q --changelog openssl |grep CVE-2013-0169 [root@host76 ~]# Thanks, Mike 0 -
Hi @JIKOmetrix That's happening because the patch which was implemented in an earlier version of OpenSSL wouldn't be listed as a patch anymore on the newer version. Basically, they don't carry it over in the changelog. This issue doesn't affect CentOS 7 servers based on the newer version of OpenSSL. The version of OpenSSL you're running isn't even listed as an affected version for this CVE which you can see NVD - CVE-2013-0169 What were their recommendations? 0 -
Hello, They are accepting what you said. Since it was patched on CentOS7 that works for them. I'll leave this be. Thanks, Mike 0 -
Hi @JIKOmetrix I'm really happy to hear that! Thanks for the update on it as well. 0
Please sign in to leave a comment.
Comments
8 comments