Verify Enabled Cipher Suites in HTTPS Inspection

[Jessa_Haines]

Happy Holidays everyone -

This is regards to: R77.30 Gateway on Take_286

Can anyone guide me to a command or configuration setting within IPS (or wherever it resides) for what Cipher Suites we currently have enabled for HTTPS Inspection?

In a nutshell, we are evaluating TCP Dump data as we are not able to load a particular site on our network. It appears our firewall is sending SSLv3.0 @ Hello and the responding Client, not server, is basically just sending us an SYN ACK back in return that we sent prior to the hello. This site does NOT support anything other then TLS 1.2. We want to confirm our cipher suites for 1.2 have a match with the list we have grabbed from the SSL test we ran on their site.

The command i found on a similar article (i thought) was: cat /opt/CPshrd-R77/registry/HKLM_registry.data | grep -i cptls

Which resulted in me getting:

cptls_ec_p384 (1)
cptls_accept_ecdhe (1)
....propose
cptls_accept_ecdsa (1)
....propose

I cannot figure out what this means as both propose and accept are being listed. Is their documentation on this formatting/response? Any help is appreciated.

Thanks in advance.

[PhoneBoy]

There is some discussion about Cipher Suites here: HTTPS Inspection Enhancements in R77.30 and above 

As well as here: Supported cipher suites for HTTPS Inspection 

[Timothy_Hall]

HTTPS Inspection negotiations are primarily handled by the wstlsd daemon. Here are the list of cipher suites supported on R80.10 vanilla, pretty sure this will be the same for R77.30.  Just because a suite is listed here doesn't necessarily mean that wstlsd permits it to be used by default (case in point: sk110883 - Specific HTTPS sites that use ECDHE ciphers are not accessible when HTTPS Inspection is e...), but if a cipher suite does not appear in this list I'm pretty sure that means wstlsd won't support it for HTTPS Inspection. 

I would imagine these are all valid for TLS 1.2 but I don't know how to verify that.  wstlsd does not appear to support "Suite B for TLS 1.2" if that is relevant to your situation.

ADH-AES128-GCM-SHA256
ADH-AES128-SHA
ADH-AES128-SHA256
ADH-AES256-GCM-SHA384
ADH-AES256-SHA
ADH-AES256-SHA256
ADH-CAMELLIA128-SHA
ADH-CAMELLIA256-SHA
ADH-DES-CBC3-SHA
ADH-SEED-SHA
AECDH-AES128-SHA
AECDH-AES256-SHA
AECDH-DES-CBC3-SHA
AECDH-NULL-SHA
AECDH-RC4-SHA
DH-DSS-AES128-GCM-SHA256
DH-DSS-AES128-SHA
DH-DSS-AES128-SHA256
DH-DSS-AES256-GCM-SHA384
DH-DSS-AES256-SHA
DH-DSS-AES256-SHA256
DH-DSS-CAMELLIA128-SHA
DH-DSS-CAMELLIA256-SHA
DH-DSS-SEED-SHA
DH-RSA-AES256-SHA256
DH-RSA-CAMELLIA128-SHA
DH-RSA-CAMELLIA256-SHA
DH-RSA-SEED-SHA
DHE-DSS-AES128-GCM-SHA256
DHE-DSS-AES128-SHA
DHE-DSS-AES128-SHA256
DHE-DSS-AES256-GCM-SHA384
DHE-DSS-AES256-SHA
DHE-DSS-AES256-SHA256
DHE-DSS-CAMELLIA128-SHA
DHE-DSS-CAMELLIA256-SHA
DHE-DSS-SEED-SHA
DHE-RSA-AES256-SHA256
DHE-RSA-CAMELLIA128-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-RSA-SEED-SHA
ECDH-ECDSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-SHA
ECDH-ECDSA-AES128-SHA256
ECDH-ECDSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-SHA
ECDH-ECDSA-AES256-SHA384
ECDH-ECDSA-DES-CBC3-SHA
ECDH-ECDSA-NULL-SHA
ECDH-ECDSA-RC4-SHA
ECDH-RSA-AES128-GCM-SHA256
ECDH-RSA-AES128-SHA
ECDH-RSA-AES128-SHA256
ECDH-RSA-AES256-GCM-SHA384
ECDH-RSA-AES256-SHA
ECDH-RSA-AES256-SHA384
ECDH-RSA-DES-CBC3-SHA
ECDH-RSA-NULL-SHA
ECDH-RSA-RC4-SHA
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA384
ECDHE-ECDSA-DES-CBC3-SHA
ECDHE-ECDSA-NULL-SHA
ECDHE-ECDSA-RC4-SHA
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-DES-CBC3-SHA
ECDHE-RSA-NULL-SHA
ECDHE-RSA-RC4-SHA
EDH-DSS-DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA
EXP-ADH-DES-CBC-SHA
EXP-ADH-RC4-MD5
EXP-DES-CBC-SHA
EXP-DH-DSS-DES-CBC-SHA
EXP-DH-RSA-DES-CBC-SHA
EXP-EDH-DSS-DES-CBC-SHA
EXP-EDH-RSA-DES-CBC-SHA
EXP-RC2-CBC-MD5
EXP-RC4-MD5
GOST2001-GOST89-GOST89
GOST2001-NULL-GOST94
GOST94-GOST89-GOST89
GOST94-NULL-GOST94
IDEA-CBC-SHA
NULL-MD5
NULL-SHA256
PSK-3DES-EDE-CBC-SHA
PSK-AES128-CBC-SHA
PSK-AES256-CBC-SHA
PSK-RC4-SHA
SRP-3DES-EDE-CBC-SHA
SRP-AES-128-CBC-SHA
SRP-AES-256-CBC-SHA
SRP-DSS-3DES-EDE-CBC-SHA
SRP-DSS-AES-128-CBC-SHA
SRP-DSS-AES-256-CBC-SHA
SRP-RSA-3DES-EDE-CBC-SHA
SRP-RSA-AES-128-CBC-SHA
SRP-RSA-AES-256-CBC-SHA

--
My Book "Max Power: Check Point Firewall Performance Optimization"
Second Edition Coming Soon

[Jessa_Haines]

Dameon Welch Abernathy‌ and @timhall  - Cheers for the replies guys. I have already checked out the links you provided Dameon. What I am looking for is a way to confirm what ciphers are allowed through HTTPS on our device, visually in some type of list form. Take note of the list i included in my post about proposing/accept, i would love to know what that is referring to as another post stated this is where you can see what ciphers are accepted or not. @Timhall thanks for the explanation of how https is getting its ciphers. I will continuing reading on this and see if i can make any further progress on this front. Happy Holidays!

[PhoneBoy]

One of the SKs I linked above mentions this: SSL Server Test (Powered by Qualys SSL Labs) 

This will tell you what ciphers are supported by a given site.

[Jelle_Hazenberg]

The most accurate and effective way to accomplish this is in my opinion is to use nmap with the ssl-enum-ciphers script.

Just install nmap and download the script on a linux machine and you can scan a target host for the supported ciphers with the supported SSL/TLS version. 

You should get a output like this for example:

Starting Nmap 6.40 ( http://nmap.org ) at 2018-02-13 15:34 CET
Nmap scan report for google.nl (216.58.210.3)
Host is up (0.0072s latency).
rDNS record for 216.58.210.3: fra16s07-in-f3.1e100.net
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.1:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.2:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds

I am facing a similiar issue at one of our customers at the moment. When we enabled the support for ECDHE we are getting the following output:

Host is up (0.021s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
|_ least strength: strong

We now only support TLSv1.0 ???

Please let me know if you find any solution for this issue. 

Edit:

Also i use a tool called testssl.sh which i use to display the server's picks: protocol+cipher. (You can use the -P flag for that.)

Kind regards,

Jelle

[PhoneBoy]

That might be worth a case with the TAC as that doesn't sound right...

[MrSaintz]

Hello,

Setting both accept flags seem unproductive, using accept forces the engine just negotiate ECDHE and ECDSA in “Only”. To allow/choose either use “propose” in this case, for accept option you can only choose “Only” ECDHE or “Only” ECDSA using the accept option. 

This info is available in sk104717 I believe is the one of the cases PhoneBoy shared here.