Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
3d150n
Participant

TLS1.0 on appliance management portals

Jump to solution

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

0 Kudos
1 Solution

Accepted Solutions
Ethan_Schorer
Employee
Employee

@genisis__ ,

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.

View solution in original post

16 Replies
PhoneBoy
Admin
Admin

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?

0 Kudos
genisis__
Advisor

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.

0 Kudos
Ethan_Schorer
Employee
Employee

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

genisis__
Advisor

Is the SK also relevant to R81.x?

0 Kudos
Ethan_Schorer
Employee
Employee

Yes, @genisis__ 

That's one of the changes that we're putting into the SK - the supported versions.

0 Kudos
genisis__
Advisor

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?

 

0 Kudos
PhoneBoy
Admin
Admin

Pretty certain this needs to be applied on each gateway also. 

Ethan_Schorer
Employee
Employee

@genisis__ ,

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.

View solution in original post

genisis__
Advisor

Would suggest the back-out procedure is also included in the SK.

0 Kudos
3d150n
Participant

@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:~#

0 Kudos
Ethan_Schorer
Employee
Employee

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

0 Kudos
3d150n
Participant

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

 

Ethan_Schorer
Employee
Employee
genisis__
Advisor

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?

 

0 Kudos
genisis__
Advisor

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.

0 Kudos
3d150n
Participant

Hi @genisis__ 

I have already done this procedure as descibed on sk147272 but it only affects the web server on port 443

Regards

Edison

0 Kudos