Some issues with SSL security and POP3/IMAP

[speckados]

Hi.

When check my servers (update with 70.0.34) get some issues:

1. Cipher incorrect
2. Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), potential DoS threat
3. SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers
4. 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)
5. 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?

 

[cPanelLauren]

Hi @speckados

What are you using to test with? Are your settings default?


Thanks!

 

[speckados]

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 regards

 

[JIKOmetrix]

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

 

[cPanelLauren]

Hi @JIKOmetrix

You should be able to see if you have the patch for this in your version of OpenSSL by running the following:

[[email protected] ~]# 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.

 

[JIKOmetrix]

Hello,

I'm on CentOS7.6 and OpenSSL 1.0.2k-fips 26 Jan 2017. I performed the command and received no output.

[[email protected] ~]# rpm -q --changelog openssl |grep CVE-2013-0169
[[email protected] ~]#

Thanks,
Mike

 

[cPanelLauren]

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?

 

[JIKOmetrix]

Hello,

They are accepting what you said. Since it was patched on CentOS7 that works for them.

I'll leave this be.

Thanks,
Mike

 

[cPanelLauren]

Hi @JIKOmetrix


I'm really happy to hear that! Thanks for the update on it as well.