HTTPS inspection of TLS1.3 and USFW

[Wolfgang]

Following Inspection of TLS v1.3 Traffic inspection of TLS1.3 is enable by default if you run USFW.

But will this be a requirement, inspection of TLS 1.3 will be supported only if USFW is enabled ?

I think with a 2 core system this makes no sense.

[Thomas_Eichelbu]

Well i think u can enable USFW even on smaller machines.
USFW is just enabled automatically by default on larger or the newer machines, thats true, but smaller ones can run USFW too.

[Wolfgang]

@Thomas_Eichelbu  yo're right, I can enable USFW.

But still the question is it a requirement for enabling TLS 1.3 inspection? 

And I think there are no advantages on a 2 core system enabling USFW...

[PhoneBoy]

USFW is a requirement for TLS 1.3 Inspection, yes.

[Timothy_Hall]

Almost all new firewall models will utilize USFW by default regardless of the number of cores; the FutureX Hardware Security Module (HSM) for Scalable Platforms and TLS 1.3 inspection require USFW.  My impression is that most new major features going forward will only be available in USFW mode to keep Check Point from having to port these new features back into Kernel Mode and test them.  The future is USFW regardless of the number of cores present due to Linux kernel memory limitations, but agree that USFW really doesn't make sense with a low number of cores but that is the direction things are going.  Having the code for new features running in user/process space is much more forgiving than running in kernel space, where even one little bug could crash the entire system.  If a process crashes no big deal the kernel cleans up the mess and the process is restarted.

[Wolfgang]

We enabled USFW to get TLS 1.3 inspection working on a 2 core open server gateway.

1. cpprod_util FwSetOverrideMode 1
2. cpprod_util FwSetUsermode 1
3. cpprod_util FwSetUsfwMachine 1
4. reboot

TLS1.3 inspection only done for incoming traffic. Gateway crashes sometimes with errors like this:

„Unable to open ‚/vs0/dev/fw0‘: Connection refused“

Apr 27 08:17:46 2022 firewall-node1 kernel: fwk0_1[7283]: segfault at 248 ip 00007f4ee8833ecb sp 00007f4e8f8ffae0 error 4 in libcpopenssl.so.1.1[7f4ee8557000+39c000]

TAC is involved but maybee someone makes one's point.

[Thomas_Eichelbu]

Hello Wolfgang, 

have you checked this SK sk92810
"Unable to open '/vs0/dev/fw0': Connection refused' during boot or cpstart, FWK_WD process is terminated after reboot"

it states that " $FWDIR/boot/modules/fwkern.conf" might be corrupted...

R81.10 manual CP_R81.10_ThreatPrevention_AdminGuide.pdf says on page 262:

Inspection of TLS v1.3 Traffic
From R81, the Check Point Security Gateway can inspect traffic that relies on Transport Layer Security (TLS) v1.3 (see RFC 8446).
From R81.10, this feature is enabled by default for Security Gateways (and Cluster Members) that use the User-Space Firewall Mode (USFW)).
For the list of supported platforms, see sk167052.
Important - In a Cluster, you must configure all the Cluster Members in the same way.
Note - To disable the inspection of the TLS v1.3 traffic for testing purposes, set the value of the global parameter fwtls_enable_tlsio to 0 and reboot.
The HTTPS Inspection feature decrypts traffic for better protection against advanced threats, bots, and other malware.

so you must set "fwtls_enable_tlsio" in fwkern.conf to "1" i suspect ...

[Wolfgang]

Yeah we checked this before, everything is fine. "fwtls_enable_tlsio" is set to "1".

It's enabled by default if you switch to USFW.

TLS1.3 inspection is running but the crashes are the problems.