- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: TLS1.0 on appliance management portals
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
TLS1.0 on appliance management portals
Hello Guys
After a vulnerability scan on the management network, it was discovered that the web portals of the Management Server r80.40 are accepting TLS1.0
We have applied sk147272: Vulnerability scan shows that Gaia Portal supports SSL medium strength cipher suites and disabled the TLS1.0 and TLS1.1 from the web portals that run on port 443
As this is a management server, it has the certificate authority running, so there is the ICA Management Tool running on port 18265 and still accepting TLS1.0
Do you know what configuration file I have to change in order to disable TLS1.0 for the web server on port 18265 that holds the ICA Management Tool?
Thanks in advance
Edison
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In order to revert the change - it is more correct to delete the registry key.
So to recap, in order to enforce the use of a minimum version of TLSv1.2:
ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CKPSSL_MIN_TLS_VERSION TLS1.2
and then restart the services (cpstop ; cpstart).
In order to revert the change, run:
ckp_regedit -d SOFTWARE\\CheckPoint\\FW1 CKPSSL_MIN_TLS_VERSION
and then restart the services (cpstop ; cpstart).
This procedure needs to be done on every gateway/management machine separately.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The ICA Management Tool is off by default and, if I understand the various SKs, should be disabled when you are not using it.
That said, seems reasonable we should be able to disable TLS 1.0.
@Ethan_Schorer is this something you can help with?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is TLS 1.0 even still used in R81.x? I would have though this should be removed by now and have a minimum version of TLSv1.2 but prefer TLSv1.3.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @3d150n ,
You can follow the guidelines in sk121356 for setting the minimum to TLSv1.2 (I know the SK is about TE - but it affects this portal as well - I'm working on updating the SK).
Basically, this is what needs to be run in Expert mode:
[Expert@GW]# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CKPSSL_MIN_TLS_VERSION TLS1.2
[Expert@GW]# cprestart
Best regards,
Ethan
p.s. Thank you to @matangi for the guidance
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is the SK also relevant to R81.x?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, @genisis__
That's one of the changes that we're putting into the SK - the supported versions.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So to recap, in order to enforce the use of a minimum version of TLSv1.2 for all SSL control connections we simply run:
ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CKPSSL_MIN_TLS_VERSION TLS1.2
and then restart the services.
Additionally if we wanted to revert the change then we would paste the below?
ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CKPSSL_MIN_TLS_VERSION TLS1.0
Also is this procedure specific to the management layer or does it apply to gateways as well?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Pretty certain this needs to be applied on each gateway also.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In order to revert the change - it is more correct to delete the registry key.
So to recap, in order to enforce the use of a minimum version of TLSv1.2:
ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CKPSSL_MIN_TLS_VERSION TLS1.2
and then restart the services (cpstop ; cpstart).
In order to revert the change, run:
ckp_regedit -d SOFTWARE\\CheckPoint\\FW1 CKPSSL_MIN_TLS_VERSION
and then restart the services (cpstop ; cpstart).
This procedure needs to be done on every gateway/management machine separately.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Would suggest the back-out procedure is also included in the SK.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Ethan_Schorerjust one last thing:
is there any way to disable 3des from the ciphers?
Best regards
root@tester:~# nmap --script ssl-enum-ciphers -p 18265 aa.bb.cc.dd
Starting Nmap 7.92 ( https://nmap.org ) at 2021-10-18 16:20 UTC
Nmap scan report for aa.bb.cc.dd
Host is up (0.00027s latency).
PORT STATE SERVICE
18265/tcp open unknown
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Forward Secrecy not supported by any cipher
|_ least strength: C
MAC Address: 00:0C:29:71:D2:C7 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.51 seconds
root@tester:~#
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @3d150n ,
Please see our response to Sweet32 attack at sk113114 (and why we aren't vulnerable).
If you want to disable, the instructions are in the SK (I believe for this port you should follow the section labeled "instructions for HTTPS Inspection, Identity Awareness Portal, ICA Portal, SmartManagement Portal, SecurePlatform WebUI")
Ethan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you very much to all the community
both registry keys (from sk121356 and sk113114) helped me to fix the issue. There are not any new discovery from the security scanner
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is now documented in sk121356:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can I confirm the procedure is also the same for MDSM? ie. switch into the DMS then run the procedure, or run from the main starting point?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I posted this a while back, but you could try this:
Here is what I did:
clear
ls -l /web/templates/httpd-ssl.conf.templ
#Note: Above just confirms permissions set back to read-only.
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
ls -l /web/templates/httpd-ssl.conf.templ
#Note: Above just confirms permissions set back to read-only.
I then ran an sslscan against the IP which resulted in only TLSv1.3 being seen.
Testing SSL server aa.bb.cc.dd on port 443 using SNI name aa.bb.cc.dd
SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 disabled
TLSv1.1 disabled
TLSv1.2 disabled
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
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
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
What I'm not sure about is if this procedure would need to run again after updating the jumbo.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @genisis__
I have already done this procedure as descibed on sk147272 but it only affects the web server on port 443
Regards
Edison
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is there a difference between sk147272 and sk154532 related to TLS? 532 seems like an easier way to disable TLS1.0.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you're just concerned about TLS 1.2, then sk154532 is adequate.
If you need to adjust further (e.g. only certain ciphers be enabled) then you need sk147272.
