HTTPS Weak Ciphers and other vulnerabilities

[Miguel089]

Hello everyone,

we just updated our Gateways to R80.30 including JH T155. We also wanted to seize the opportunity to harden the web portal so we used cipher_util to deactivate several Ciphers:

Enabled:
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Disabled:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA

After this, the vulnerability scan looks much better. Only one vulnerability is left:

Secure Client-Initiated Renegotiation     VULNERABLE (NOT ok), DoS threat

The recommendation from Qualys is to  check for client-initiated renegotiation support in your servers, and disable it where possible. Is there a way to perform this in Gaia?

There is an IPS Protection to block this kind of exploit, but I think this refers to external Web Servers, not to the firewall’s own service. In any case, we're not doing IPS on this gateway anyways.

Therefore, I'm looking for a way to disable the response to the client-initiated renegotiation on the Check Point gateway.

Thank you in advance!

Br,

Miguel

[PhoneBoy]

Can you provide some details of what this vulnerability is and precisely in what context it was found?
It's not clear from context.

[Miguel089]

Hi,

as described here: https://blog.qualys.com/ssllabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks, in 2011 a group of hackers released an DoS tool that works at the SSL/TLS layer. The tool is exploiting the fact that, when a new SSL connection is being negotiated, the server will typically spend significantly more CPU resources than the client. Thus, if you are requesting many new SSL connections per second, you may end up causing high CPU load. The tool uses the renegotiation feature, which means that it can force a server to perform many expensive cryptographic operations over a single TCP connection.

The vulnerability Scan was performed with testssl.sh. this is the entire output:

Testing protocols via sockets except NPN+ALPN 

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    not offered and downgraded to a weaker protocol
 NPN/SPDY   not offered
 ALPN/HTTP2 not offered

 Testing cipher categories 

 NULL ciphers (no encryption)                  not offered (OK)
 Anonymous NULL Ciphers (no authentication)    not offered (OK)
 Export ciphers (w/o ADH+NULL)                 not offered (OK)
 LOW: 64 Bit + DES, RC[2,4] (w/o export)       not offered (OK)
 Triple DES Ciphers / IDEA                     not offered
 Obsolete: SEED + 128+256 Bit CBC cipher       not offered
 Strong encryption (AEAD ciphers)              offered (OK)


 Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4 

 PFS is offered (OK)          ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 
 Elliptic curves offered:     prime256v1 secp384r1 secp521r1 X25519 


 Testing server preferences 

 Has server cipher order?     yes (OK)
 Negotiated protocol          TLSv1.2
 Negotiated cipher            ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
 Cipher order
    TLSv1.2:   ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 


 Testing server defaults (Server Hello) 

 TLS extensions (standard)    "renegotiation info/#65281"
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID: yes
 TLS clock skew               -1 sec from localtime
 Signature Algorithm          SHA256 with RSA
 Server key size              RSA 4096 bits
 Server key usage             Digital Signature, Key Encipherment
 Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
 Serial / Fingerprints        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX / SHA1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
                              SHA256 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 Common Name (CN)            xxxxxx.com 
 subjectAltName (SAN)         xxxxx.com www.xxxxx.com 
 Issuer                       Sectigo RSA Domain Validation Secure Server CA (Sectigo Limited from GB)
 Trust (hostname)             Ok via SAN (same w/o SNI)
 Chain of trust               Ok   
 EV cert (experimental)       no 
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   703 >= 60 days (2020-03-24 01:00 --> 2022-03-25 00:59)
 # of certificates provided   4
 Certificate Revocation List  --
 OCSP URI                     http://xxxxxx.com
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     yes (certificate extension)


 Testing HTTP header response @ "/" 

 HTTP Status Code             403 Forbidden
 HTTP clock skew              +1 sec from localtime
 Strict Transport Security    365 days=31536000 s, includeSubDomains
 Public Key Pinning           --
 Server banner                CPWS
 Application banner           --
 Cookie(s)                    (none issued at "/") -- maybe better try target URL of 30x
 Security headers             X-Frame-Options DENY
 Reverse Proxy banner         --


 Testing vulnerabilities 

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 Ticketbleed (CVE-2016-9244), experiment.  not vulnerable (OK), no session ticket extension
 ROBOT                                     Server does not support any cipher suites that use RSA key transport
 Secure Renegotiation (RFC 5746)           supported (OK)
 Secure Client-Initiated Renegotiation     VULNERABLE (NOT ok), DoS threat
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK)
 BREACH (CVE-2013-3587)                    no HTTP compression (OK)  - only supplied "/" tested
 POODLE, SSL (CVE-2014-3566)               not vulnerable (OK), no SSLv3 support
 TLS_FALLBACK_SCSV (RFC 7507)              No fallback possible (OK), no protocol below TLS 1.2 offered
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    not vulnerable (OK)
 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=3A0E135717080B8691C45310E5D1A6FB0D54D37C54DB0B1E0F5002ED69302076 could help you to find out
 LOGJAM (CVE-2015-4000), experimental      not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
 BEAST (CVE-2011-3389)                     not vulnerable (OK), no SSL3 or TLS1
 LUCKY13 (CVE-2013-0169), experimental     not vulnerable (OK)
 RC4 (CVE-2013-2566, CVE-2015-2808)        no RC4 ciphers detected (OK)


 Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength 

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 256   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384              
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 256   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   

The recommendation is to deactivate client-initiated renegotiation support in the web server. IIS, for example, does not support client-initiated renegotiation. Apache used to, but changed its behaviour when implementing RFC 5746.

[Lukas_Sosnovec]

Hi,

Any news about renegotiation problem? SK search returns zero results, I cannot believe that security vendor as CheckPoint has no advisory?

[G_W_Albrecht]

There is an IPS protection covering it already !

[Lukas_Sosnovec]

Yes, I am aware of that.

But I am talking about CheckPoint implementation of ssl (It is MAB portal specifically). Pentest of current r80.30 implementation says it is vulnerable. I believe Miguel's question was about this as well.

[quatloo]

Hello,

I have observed different results for this type of testing, depending on the testing tool. Regarding client-initiated renegotiation testing specifically, one tool I commonly use (sslyze) reports that one of my websites does not have this vulnerability when I do not use HTTPS inspection. But when I turn on HTTPS inspection for the website, the same tool reports that the website does have the vulnerability. In both cases (with and without HTTPS inspection) Qualys reports that the website is not vulnerable.

I think one needs to use a more functional, interactive test to sort these conflicts out, and I typically resort to OpenSSL. This is a good summary of some of the possible testing scenarios:

Manually Testing SSL/TLS Weaknesses
https://www.contextis.com/en/blog/manually-testing-ssl-tls-weaknesses

Additionally, I have both of the TLS renegotiation IPS protections enabled on my R80.20 gateway. When testing with sslyze, the IPS protection is not triggered; when testing with Qualys, the IPS protection is triggered; when testing with OpenSSL, the IPS protection is triggered.

At the end of the day, I have accepted that I am probably not vulnerable to the client-initiated renegotiation, despite what one of my testing tools reports.

Good luck!