Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Mattias_Jansson
Contributor

Outbound https inspection and SNI on R80.20

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.

 

20 Replies
PatrikSkoglund
Contributor

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
Contributor

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

0 Kudos
Reply
mdjmcnally
Advisor

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
Advisor

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.

0 Kudos
Reply
Mattias_Jansson
Contributor

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
Advisor

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

0 Kudos
Reply
Mattias_Jansson
Contributor

Yes. Both on should work from R80.20.
0 Kudos
Reply
KS
Participant

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
Contributor

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

0 Kudos
Reply
KS
Participant

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
Contributor

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.
0 Kudos
Reply
KS
Participant

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
Collaborator

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
Participant

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

Nik_Bloemers
Collaborator

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?
0 Kudos
Reply
KS
Participant

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
Contributor

Sounds promising! Thanks for keeping us in the loop!
0 Kudos
Reply
Nik_Bloemers
Collaborator

We're running T155 for some time but we still have these issues.
0 Kudos
Reply
Mattias_Jansson
Contributor

Great news. Thanks for the update!
Fabio_Fukushima
Explorer

KS, 

 

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

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

0 Kudos
Reply