HTTPS Inspection with Google Chrome Omnibox Issue

[The_Dude]

Hello All,

I started testing the HTTPS Inspection / Application Control Blade / URL Filtering on my egress firewall. I have about 10 users in my test group and imported the ICA certificate I created in CP to the users Trusted Root CA. Right away I started noticing issues with Google Chrome. When a user would use the "omnibox" (URL bar) for searching in Chrome, sometimes the user will get this string as a response with a blank page "https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8". I called into CP support and my CP Sales rep and as they try to mimic my environment they have not yet been able to re-create the issue. I believe it is something tied to the HTTPS Inspection, because when I bypass the category search engines for the group, the issue goes away.

I searched Google Chrome Support and seen similar issues with Chrome a couple years back. I am stuck in the middle thinking its a Chrome issue or a Check Point HTTPS Inspection issue. I have about 5,000+ other users that don't go through the HTTPS Inspection and no one has reported an issue. Its only happening to the people in the test group for HTTPS Inspection.

I am running R77.30 GAIA n an Open Server with FW, Adv Net, IPS, Threat Prevention, AV, AB, URLF, and App Control.

The default Google Chrome Search String for omnibox is: {google:baseURL}search?q=%s&{google:RLZ}{google:or iginalQueryForSuggestion}{google:assistedQueryStat s}{google:searchFieldtrialParameter}{google:iOSSea rchLanguage}{google:searchClient}{google:sourceId} {google:instantExtendedEnabledParameter}{google:co ntextualSearchVersion}ie={inputEncoding}

The 2 workarounds I have for this is:
1. Change Default Chrome search string to be: https://www.goolge.com/search?q=%s
2. Bypass HTTPS Inspection on category Search Engines

Has anyone else ran into this issue?

[ShadowPeak.com]

Hello All,

I started testing the HTTPS Inspection / Application Control Blade / URL Filtering on my egress firewall. I have about 10 users in my test group and imported the ICA certificate I created in CP to the users Trusted Root CA. Right away I started noticing issues with Google Chrome. When a user would use the "omnibox" (URL bar) for searching in Chrome, sometimes the user will get this string as a response with a blank page "https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8". I called into CP support and my CP Sales rep and as they try to mimic my environment they have not yet been able to re-create the issue. I believe it is something tied to the HTTPS Inspection, because when I bypass the category search engines for the group, the issue goes away.

I searched Google Chrome Support and seen similar issues with Chrome a couple years back. I am stuck in the middle thinking its a Chrome issue or a Check Point HTTPS Inspection issue. I have about 5,000+ other users that don't go through the HTTPS Inspection and no one has reported an issue. Its only happening to the people in the test group for HTTPS Inspection.

I am running R77.30 GAIA n an Open Server with FW, Adv Net, IPS, Threat Prevention, AV, AB, URLF, and App Control.

The default Google Chrome Search String for omnibox is: {google:baseURL}search?q=%s&{google:RLZ}{google:or iginalQueryForSuggestion}{google:assistedQueryStat s}{google:searchFieldtrialParameter}{google:iOSSea rchLanguage}{google:searchClient}{google:sourceId} {google:instantExtendedEnabledParameter}{google:co ntextualSearchVersion}ie={inputEncoding}

The 2 workarounds I have for this is:
1. Change Default Chrome search string to be: https://www.goolge.com/search?q=%s
2. Bypass HTTPS Inspection on category Search Engines

Has anyone else ran into this issue?

Chrome gets really honked off when trying to talk to Google-owned sites (including youtube) and a firewall is attempting to mess with the connection, regardless of whether it is trying to insert a UserCheck notification or performing full-blown HTTPS Inspection. See this all the time in the Secure Web Gateway (SWG) class I teach which as a result has constantly-changing lab errata. :-(

Start your reading here:

https://www.chromium.org/hsts (relevant to trying to insert HTTP UserChecks when HTTPS Inspection is not enabled)

https://developers.google.com/web/up...hrome-46?hl=en (with HTTPS Inspection Chrome refuses to connect to google-owned sites)

Later versions of Firefox are starting to get various degrees of cranky about this as well...

[aweldon]

Not sure if you are having the same issue as me but in a similar occurrence when searching from the omnibox Chrome uses UDP 443 / QUIC protocol. I have heard that by default if you block UDP 443 Chrome is supposed to fall back to TCP. My browser was very stubborn and did not want to fall back in a timely fashion. Also, Check Point does not support inspection of QUIC as of yet from what I have read. Another thing don't forget to review Google Cache as it can still allow users to view potentially blocked content!