Outbound https inspection and SNI on R80.20

[Mattias_Jansson]

Hi!

I am a bit confused about https inspection and SNI-support.

We are running r80.20 take 80 with https inspection and we alse have enabled the "Categorize HTTPS websites" for non https-inspection machines.

Lately we encounter strange behaviours with websites running in Cloudflare.

ssllabs shows: "This site works only in browsers with SNI support." and most of them only supports ESCDA cipher suites that is only supported from the gateway to the server in R80.20

One example of the behaviour

Client using chrome (same issue with other browsers) to access https://oauth.net

Pcap from the client: Client web browser sends Client Hello , SNI=oauth.net

The gateway tries to connect to the server and tries the supported cipher suites.

Pcap from the gateway: After a while (after failing several times without sending ECDSA ciphers) they connect with the supported ECDSA cipher and the server sends correct SAN-names:
*.oauth.net, sni.cloudflare.com and oauth.net

Pcap from the client:

The client recieves wrong SAN-names: api2.hitta.se and sni.cloudflare.com and the web browser displays a certificate warning.

All wrong SAN-names displayed are also hosted on cloudflare, so my theory is that the firewall has cached the SAN-names and the corresponding ip-address.

After hitting F5 alot of times and accepting the wrong certificate the client can connect.

My questions:

Why is the client getting wrong SAN-names from the gateway?

Is there a https-cache (SAN-names to corresponding ip-address) that is causing this?

If so, can it be cleared?

Is there a way to get around this issue without disabling https-inspection to the cloudflare /14 subnet without upgrading to R80.30?

Adding screenshots of the behaviour.

[PatrikSkoglund]

We have the same issue. I've run a lengthy ticket with Check Point. It's fixed in R80.30 and won't be fixed in R80.20.

[Mattias_Jansson]

Do you know if this is caused because we are running https-inspection + having "Categorize HTTPS websites" enabled at the same time?

[mdjmcnally]

I'll be honest I don't know as normally I always have 1 or the other enabled, not both.

The R77.30 has more information in it's help where says that is basically ignores the option if HTTPS Inspection is enabled, but I couldn't state 100% that is true still for R80.x.

[mdjmcnally]

Not saying will fix this however there are a number of enhancements for SNI and HTTPS Inspection in R80.20 i Jumbo Take 117.

There is a new GA Take 127 that has this.

Might possibly be worth looking at patching to this.

Normally you should only have the Categorise HTTPS sites when not doing HTTPS Inspection.

The R77.30 contains this in the information.

The Categorize HTTPS sites option does not run if:

• HTTPS Inspection is enabled.
• There is a proxy between the destination site and the firewall (or the firewall functions as a proxy).

  The destination site is categorized according to IP address. The site URL is extracted from the SSL CONNECT request the client sends to the Proxy.

Don't know if that is changed with R80 to be honest.

[Mattias_Jansson]

The Categorize HTTPS websites is set SmartConsole. I want it disabled on the fw that is running https-inspection. Enabled on the others. Not sure how to achieve that?

[mdjmcnally]

It is a Global Setting is either on or off, which then goes to ALL Firewalls in that Management System.

[Mattias_Jansson]

Yes. Both on should work from R80.20.

[KS]

Hello

Having the same issue on 80.30 with  JHF 140

Https inspection and Categorization are both enabled.

Were you able to dig to the core of this problem ?

[Mattias_Jansson]

No. I was hoping that they had solved it on R80.30.  😕

[KS]

We opened a ticket for this.

CP gave me a hotfix wrapper almost instantly.

We will install it in maintenance window, so I will let you know if it works as expected.

Hotfix is for particular R and JHF.

[PatrikSkoglund]

Sound good! Please report back if it's working now! We're in the process of upgrading aswell.
Also if you still have the case open. Ask if the wrapper is coming in a jumbo soon.

[KS]

We installed HF Wrapper and looks like it did the trick.

As far as we can check Cloudflare SNI pages are opening with proper certificates, including oauth 😉

At least we were not able to replicate this problem any more.

[Nik_Bloemers]

That's awesome. Can you ask when this will be available in Jumbo hotfix? We're facing this issue too but would like to avoid special/version specific hotfixes if we can.

[KS]

I did but didn't get any answer up till now.

[Nik_Bloemers]

Did you get a response in meantime? Or can anyone from Check Point let us know when we can expect this to be a more mainstream hotfix or part of jumbo?

[KS]

I still didnt get any answer from Support and probably won't get any, but there is a light in a tunnel 😉

Today I had to uninstall wrapper provided for SNI problems as we had to instal new GA JHF 155. 

I don't know if it was just luck but tested sites we had issues with SNI before and couldn't replicate wrong behaviour, so seems like it might be incorporated in 155 but release notes are not telling a thing about it.

[PatrikSkoglund]

Sounds promising! Thanks for keeping us in the loop!

[Nik_Bloemers]

We're running T155 for some time but we still have these issues.

[Mattias_Jansson]

Great news. Thanks for the update!

[Fabio_Fukushima]

KS, 

Please could you share the name of this Hotfix wrapper file?

I'm facing this issue and i'm looking for this hotfix.