- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Guys,
I'm trying to lockdown the GAIA Portal and as such done the below which works, however the odd thing is, I expect TLSv1.2 and TLSv1.3 to work. When I did a test using SSLScan to just see what what ciphers are exposed, the output showed that TLS1.2 is disabled.
SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 disabled
TLSv1.1 disabled
TLSv1.2 disabled
TLSv1.3 enabled
On the gateway we can see TLSv1.2 has one cipher enabled:
cpopenssl ciphers -v 'ECDHE-RSA-AES256-SHA384:AES256-SHA256:!ADH:!EXP:!RSA:+HIGH:+MEDIUM:!MD5:!LOW:!NULL:!SSLv2:!eNULL:!aNULL:!RC4:!SHA1'
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
I locked down the portal by using the below.
cp /web/templates/httpd-ssl.conf.templ /web/templates/httpd-ssl.conf.templ_ORIGINAL
chmod u+w /web/templates/httpd-ssl.conf.templ
sed -i 's/SSLCipherSuite HIGH:!RC4:!LOW:!EXP:!aNULL:!SSLv2:!MD5/SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:!ADH:!EXP:!RSA:+HIGH:+MEDIUM:!MD5:!LOW:!NULL:!SSLv2:!eNULL:!aNULL:!RC4:!SHA1/g' /web/templates/httpd-ssl.conf.templ
sed -i 's/SSLProtocol -ALL {ifcmp = $httpd:ssl3_enabled 1}+{else}-{endif}SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2/SSLProtocol -ALL {ifcmp = $httpd:ssl3_enabled 1}+{else}-{endif}TLSv1.2 +TLSv1.3/g' /web/templates/httpd-ssl.conf.templ
chmod u-w /web/templates/httpd-ssl.conf.templ
/bin/template_xlate : /web/templates/httpd-ssl.conf.templ /web/conf/extra/httpd-ssl.conf < /config/active
tellpm process:httpd2
tellpm process:httpd2 t
Can anyone spot why TLSv1.2 is not shown as enabled and not finding the single cipher?
why not using cipher_util?
Will this work from Windows? I just grab whatever works on Windows to do a quick test.
I take it your referring to the tool related to sk126613
Which blade would you like to configure?
(1) Multi Portal
(2) SSL Inspection
1
Make sure the selected blade is active.
Cannot access the configuration file
Aborting...
Also the SK does not indicate if we can disable TLSv1.0, TLSv1.1
I've no license on the devices yet.
Did you finish the first time wizard yet or now? If you did not, please do.
Also, there are quite a few discussions for the matter in the community already, for example: https://community.checkpoint.com/t5/General-Topics/Disable-TLS-1-0/m-p/70338#M14237
First time wizard has been completed.
Then license is not an issue, you should have 2 weeks evaluation. Did you try your modifications before or after you used cipher_util?
before, so within the two week period.
What is the version you are using?
R81 with JHFA23
Then it might be that you have messed with HTTPd settings and corrupted the config file, then cipher_util fails. I would re-install and use cipher_util before anything else. Also, the GW should have policy installed before and after modifications.
I'm doing another build right now, so I can try it on there as well.
Sure, let me know if this works for you. If there is an issue with cipher_util, and before you make any modifications manually, please open a TAC case.
This is a new build, and the policy will be installed within the cutover window.
Clean build - same result
Clean build with JHFA23 - same result
not in all cases no license and policy installed its just a clean build ready for commissioning.
Open a support case with TAC please.
cipher_util is only relevant when you have a policy installed (and configuration such that multi-portal is active)
Same with the TLS versions configured in snx_ssl_max_ver and snx_ssl_min_ver
Without multi-portal in use, the httpd configuration is relevant.
Cool - so back to my original question then related to why TLSv1.2 shows as disabled.
More update:
I've discovered that when locking down the ciphers etc you need to be careful. The symptom I experienced was:
Logs & Monitors > General Overview or new tab "Error loading tab - Error: SslVersionOrCipherMismatch" Gateway object license tab "Loading Error: ERRL_SSL_VERSION_OR_CIPHER_MISMATCH" for more details see sk166932.
I check the KB and found SK171707, after which then lead me to the lockdown I did. At this point I tweaked the setting to the following:
SLCipherSuite HIGH:!ADH:!RC4:!DHE:!LOW:!EXP:!RSA:!eNULL:!aNULL:!SSLv2:!MD5
SSLProtocol -ALL {ifcmp = $httpd:ssl3_enabled 1}+{else}-{endif}TLSv1.1 +TLSv1.2 +TLSv1.3
When run a scan against the IP for the SMS I get the following discovered:
SLCipherSuite HIGH:!ADH:!RC4:!DHE:!LOW:!EXP:!RSA:!eNULL:!aNULL:!SSLv2:!MD5
SSLProtocol -ALL {ifcmp = $httpd:ssl3_enabled 1}+{else}-{endif}TLSv1.1 +TLSv1.2 +TLSv1.3
When run a scan against the IP for the SMS I get the following discovered:
TLSv1.3 enabled
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Session renegotiation not supported
TLS Compression:
Compression disabled
Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-ARIA256-GCM-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-ARIA128-GCM-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-CAMELLIA256-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-CAMELLIA128-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253
Server Key Exchange Group(s):
TLSv1.3 128 bits secp256r1 (NIST P-256)
TLSv1.3 192 bits secp384r1 (NIST P-384)
TLSv1.3 260 bits secp521r1 (NIST P-521)
TLSv1.3 128 bits x25519
TLSv1.3 224 bits x448
TLSv1.2 128 bits secp256r1 (NIST P-256)
TLSv1.2 192 bits secp384r1 (NIST P-384)
TLSv1.2 260 bits secp521r1 (NIST P-521)
TLSv1.2 128 bits x25519
TLSv1.2 224 bits x448
Issue was resolved in the GUI.
If anyone can suggest further tweaking please shout, as I would like to lock this down much as possible.
I experienced that myself once...playing around with those ciphers can actually cause more harm than good. I dont know if there is a better solution to this currently...
maybe the Gurus can give some guidance that will lock this down and to keep the security audit team happy, while not breaking anything.
I think what I've done is about as good as it gets without breaking something.
I agree cold heartedly. I would leave it alone if I were you.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
17 | |
12 | |
12 | |
11 | |
11 | |
7 | |
6 | |
5 | |
5 | |
5 |
Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesTue 28 Oct 2025 @ 11:00 AM (EDT)
Under the Hood: CloudGuard Network Security for Google Cloud Network Security Integration - OverviewAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY