CheckPoint SSL bypass not working (previously "... Proxy downgrades TLS version")

[JasMan]

Hi all,

We're having a strange behaviour on one of our firewalls.

Users trying to open the website https://go.sospes.com over Checkpoint proxy with HTTPS inspection enabled. But the connection times out.

I run a packet capture on the LAN and WAN interfaces and noticed that the client request is TLSv1.2 and the request on the WAN side TLSv1.0.
I'm sure that the destinatin blocks deprecated protocols like TLSv1 and thats why the users get a timeout.

But why downgrades the firewall the TLS version? It seems that this only happens for this website.

Current version: R81.10 JHF Take 174

[the_rock]

Is ssl inspection enabled?

Andy

[Lloyd_Braun]

it looks like that site only support tls v1.3 with limited ciphers. not sure if usfw still required for tls v1.3 support, that was a caveat for a while. SSL Server Test: go.sospes.com (Powered by Qualys SSL Labs) 

ciphers supported per https://support.checkpoint.com/results/sk/sk104562

looks like usfw may be required for tlsv1.3 per https://support.checkpoint.com/results/sk/sk65123

[PhoneBoy · Accepted solution]

Performing TLS Inspection for TLS 1.3 requires USFW mode to be enabled.
See: https://support.checkpoint.com/results/sk/sk167052 
Otherwise, the system will downgrade to TLS 1.2.
Since we're starting with TLS 1.2, that isn't the case here.

If this TLSv1 connection occurs from the gateway right after the user initiates the connection, this would be the SNI verification step that is sending it.
Not sure there's a way to tune that, which suggests TAC should be involved.

[Bob_Zimmerman]

Be aware Wireshark's report of TLS version is frequently misleading.

All TLS handshakes start with a Client Hello specifying TLSv1.0 (identifier 0x0301). There's then an offer inside the Client Hello to actually negotiate TLSv1.1 (0x0302) or TLSv1.2 (0x0303). Then there's an extension inside that which says the client actually supports TLSv1.3 (0x0304).

Until it sees a response, Wireshark shows the lowest possible version of the negotiation. That is almost guaranteed to be a false result caused by your actual problem, which is not getting the Server Hello.

[JasMan]

You're right. I totaly forgot about this. That's why I wrongly identified it as a TLSv1 request. ‌😬
‌

We were able to find the reason for the issue.

The site is excluded from HTTPS inspection on all our firewalls. But the rule doesn't match anymore on one firewall since last week.

The last exception logs reportet log

We've created a new rule for the bypass below the non-working rule to solve the issue.

Now we're trying to identify why the global rule is not matching on one firewall.

The last matching log entries for that firewall show an error:

"The probe detected that this destination cannot be inspected and its identity cannot be verified due to a TLS alert (TLS alert: protocol_version)"

After about 20 of this errors no more HTTP inspection logs where generated for this firewall and website.

[the_rock]

FWIW, I know its recommended to keep any any bypass at end of ssl inspection policy, but I always do any any inspect and works real well.

Andy

[PhoneBoy]

Today I learned. 🙂

[the_rock]

I bet our friend behind tcpdump101 may had not had know that either, will ask him : - )

Andy

[Bob_Zimmerman]

Here's a screenshot of a negotiation I just caught demonstrating this:

A packet capture of a connection to 1.1.1.1. A Client Hello is selected. It shows handshake version TLSv1.0, handshake protocol client hello version TLSv1.2, then extension: supported versions with support for TLSv1.3.

Incidentally, SSLv3 is protocol 0x0300, so TLSv1.0 is SSLv3.1. The actual implementation details of TLS are deeply irritating. I'm glad somebody else develops the libraries to deal with it.