- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: ckpSSL ssl lib error
- 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
ckpSSL ssl lib error
Hi all,
I was wondering whether anybody has either seen the error below before or know how to fix it.
I have already consulted sk97691 but it doesn't seem to cover the error above.
Many thanks in advance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A couple questions:
- What version of Management is this? Assuming it was upgraded at some point, what version from?
- What version of Gateway are you attempting to manage?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for responding Dameon.
Both questions are valid.
The Management version is 80.20 while the gateway's version is R70.
It goes without saying that the above deployment is not recommended by any means but my team and I were interested in figuring out whether such an implementation would be feasible. The work I've done so far took place in a virtualized environment. Please see the steps taken below:
- Connectivity between the server and the gateway is successful.
- Time is set the same on both endpoints.
- License has been installed on both machines.
- The gateway has been configured with the right settings as far as I can see:
- The gateway’s initial policy has been uninstalled (with fw unloadlocal).
- The gateway is listening on port 18191 (with netstat -nap | grep 18191).
- Captured SIC traffic with the following:
- Tcpdump -i eth0 port 18191 -w SIC_traffic.pcap
- Clicked on “Test SIC status” button to capture the interesting traffic.
- Upon opening the captured traffic on Wireshark, the 3-way TCP handshake is visible, along with the Client/Server hello packets but it ends with a decrypt error:
Due to the “packet size limited during capture” messages seen on Wireshark, I re-run tcpdump with the following syntax to capture the full packet:
Tcpdump -vvvi eth0 port 18191 -s0 -w SIC_entirepacket.pcap
The result is the following:
The TLS-handshake is now more detailed but again the gateway resets the connection as it can’t decrypt the packet.
Any help or insight would be much appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Backwards compatibility for an R80.20 SMS only extends back to gateway version R75.20, so having your SMS attempt to communicate with an R70 gateway is not supported. Is there some special reason you are using a version of software on the gateway that has not been supported for several years?
--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We only considered it due to a certain customer's production network though we were almost certain that the experiment wouldn't work anyway....
From a closer technical perspective however, would you say that it is the newer TLS ciphers that a gateway as old as R70 wouldn't support, hence being unable to decrypt the SIC traffic?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Possibly, a gateway that old will try to use 3DES instead of AES for SIC encryption, and may also try to use the deprecated SHA-1 algorithm instead of SHA-256 which the R80.20 SMS will definitely not like. A gateway that old may also try to use the deprecated SSL protocol instead of TLS. Just because you can set the version on the gateway object to something that old prior to R75.20 doesn't mean everything will still work. 🙂
--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
True, thanks very much for your input!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What you're seeing is expected behavior.
The default hash used for certificates generated by the ICA is:
- Releases prior to R80: SHA1
- R80 and above: SHA256
R71 was the first release to support SHA256 certificates.
That means for any R80+ manager trying to gateway prior to R71, if you attempt to establish SIC, it will surely fail.
See: SHA-1 and SHA-256 certificates in Check Point Internal CA (ICA)
Now, if you were managing the gateway in R77.30 and then upgraded that manager to R80+, you could still push policy to the gateway.
In fact, I tested this myself by upgrading an R77.30 Manager to R80.10 and pushing policy to an R65 gateway.
While completely and totally unsupported, it worked.
However, if I ever regenerate the SIC certificate for this gateway, SIC would likely start failing because of this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmmm. Maybe you can help me with a block on rule 995 in my R65 gateway 😉
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yikes, that brings back some memories
