Is there any workaround for SNI HTTPS traffic when enabled the HTTPS probe bypass?

[WAI_KIT_LAO]

Hello everyone, Customer now uses HTTPS inspection with probe bypass. 

He found that he could not access some website. After checked, those website site works only in browsers with SNI support.

I found the sk104717 point that the limitation of HTTPS Inspection Bypass Mechanism with enabled Probe Bypass is HTTPS Inspection will not work for sites that require SNI extension in the SSL "Client hello" packet.

I tried bypassing the URL of those websites but it still didn't work.

Is there any workaround for it? Or Is there any future plan for fixing the issue?

[William_Chang]

We got the same issue. We are running R80.10. In order to take the advantages of the "unified" policy, we will need to turn on the Application/URL blades. In order to have the firewall detect the URL properly, the https decryption would be on.

However, there are a lot of sites using SNI, most common ones are hosts solutions since people more and more moved their sites to the cloud. It is very hard to do the pro bypass on those sites. In the end, we had to disable the https decryption because we got too many support calls to deal with.

In addition, so called "ground up redesigned" R80.10 still stuck in the R77 https policy editor with no simple check box on decryption within the rules like the competitor Palo Alto.

[PhoneBoy]

SNI information is sent in plaintext, which makes it trivial to spoof.

This makes using SNI as the basis for a security decision unwise.

That said, there is a clear need for this functionality and we are investigating how to address this in a secure way.

It's also something that may be resolved in the TLS/1.3 spec. 

[Hugo_vd_Kooij]

As far as blocking is concerned I would trust SNI. If the client indicates it wants to go somewhere where I have a simple match on a blocking rule I would call it day and block the connection.

On allow rules it becomes ..... complicated.

[WAI_KIT_LAO]

I am looking forward Checkpoint improvement but does any workaround for the SNI traffic now?

The customer doesn't want to disable the HTTPS probe bypass because it can Stop the inspection of the first connection to bypassed sites.

[Albert_Wilkes]

as per sk92888 using the CP as a proxy would be a workaround when you disable probe bypass that doesn't seem to require two connections - at least there is no mention of a second connection being required. I'd hope/guess this is because the CONNECT request which presents the host in cleartext before any actual tunnel gets built

Also check this https://community.checkpoint.com/message/12721-https-inspection-probe-bypass-to-enable-or-not-to-ena... 

[D_W]

Try to create an object with the website domain and the IP of this webservice and explicitly create a bypass rule for that object(s). You will have the issue again when the IP behind this website changes.

[Amos_Reiss]

There is a fix coming in July for this issue (probe bypass with SNI) on top of R80.10.

To get it please contact your local SE and ask to open RFE ticket for solution center. 

[Norbert_Bohusch]

Can you share more details about how the issue is solved?

- automatic bypass of SNI?

- working Probe Bypass with SNI?

- or other solution I‘m not thinking about?

[Amos_Reiss]

We are going to move the rulebase decision to a later point in the connection when we are able to send the SNI and then cache would be including “verified” SNI. This should allow us to work with SNI in a secure manner. 

[WAI_KIT_LAO]

It's good to hear that improvement from you.

Does the fix work for R77.30?

[Amos_Reiss]

No, only R80.10 and later versions.

[Paul_Hagyard]

Hi Amos,

Now that we're past July, there's nothing in the R80.10 jumbo HFA notes (or other public SK articles that I could find) about an HTTPS inspection fix for probe bypass and SNI. I contacted my local SE a couple of times to clarify whether this is available but haven't got an answer. What is the status of this fix?

If the fix is not available, what is the current “recommendation” about enabling probe bypass with HTTPS inspection (for both R77.30 and R80.10)? I can see why it would be a good thing (aside from the SNI issue), but it’s not recommended under the best practices SK article (sk108202, appearing only under troubleshooting).

Cheers,

Paul

[Amos_Reiss]

Hi Paul,

The SNI HF is released already but it is not part of Jumbo HF.

This is why you will need to contact your SE / Sales representative which should contact Solution Center.

We will  release it as part of JHF later on.

Regards

Amos

[Carey_Page-Sinc]

Hi Amos,

Is it still the case that this SNI hotfix is available for R80.10 only? And not for R77.30?

How about R80.20? Is this fix incorporated into the GA release, or is still an additional hotfix?

Cheers,

—

Carey

[Amos_Reiss]

Hi Carey,

R77.30 - No plans.

R80.20 GA don't have this code yet but we do plan to have a HF for it as well.

Regards

Amos

[Robert_Gilbert]

Hi,

I received the hotfix from our SE and installed today on top of take 103 of R80.10 as advised. The problem is now that disabling probe bypass causes all HTTPS inspection traffic to fail completely. With probe bypass enabled, attempting to bypass sites based on the 'Site/Category' column above the catch all inspect rule in the HTTPS inspection policy seems to cause all HTTPS sites to be bypassed for inspection. The exception to this is where the source and destination columns do not match the traffic for the bypass rule, and pass on to the catch all inspect rule. For example if you specify an IP in the destination field to be bypassed then traffic destined to other IPs will pass this rule in the inspection rulebase. Without a bypass rule inspection works fine. This seems to effectively have caused more problems. Is anyone else aware of similar symptoms? 

[Amos_Reiss]

Robert, please ask your SE to contact me to look into this issue.

Thanks

Amos

[Darran_Lebas]

HI Robert,

Do you have any updates/feedback on the SNI hotfix? I'm planning on enabling probe bypass next week. I'm keen to hear if the SNI fix is something I should have ready to go if needed? 

[Robert_Gilbert]

Hi,

Still having the same issues. I'm speaking with a Checkpoint engineer on Thursday so hopefully will have some progress then. 

[Robert_Gilbert]

Hi

I've just had a remote session with Checkpoint and the issue was this hotfix is only for 64bit architecture. With this in mind Checkpoint are going to develop it for 32bit as well. Probe bypass is also configured by default with this hotfix (enhanced_ssl_inspection kernel parameter is now deprecated) and there are additional ciphers supported. I was told there are plans to release a wrapper for take 154 either for the end of the year or Q1 2019. 

[Darran_Lebas]

That's not great, receiving a patch that wasn't suitable for your environment .

I'd be interested to hear your thoughts once you get the 32bit version or from anyone else.

[Robert_Gilbert]

Hi,

I've tested both 64bit and 32bit hotfixes in their respective environments and they both work well. Checkpoint have also confirmed to me that there is a verification step to check the integrity of the SNI details in the packet. The SNI hostname is compared against addresses in the SAN of the certificate and failing that the Certificate CN. If neither of them can verify the SNI is genuine then the configured 'fail open/fail close' policy applies. 

[Darran_Lebas]

That's good to hear. Are you saying that the SNI hotfix has fixed most of your issues now? Are apps such as Skype now accessible?

[Robert_Gilbert]

Hi,

Everything I've tested seems to work well. Inspection issues with Skype can be avoided by bypassing the URLs the application relies on and this is now done on the SNI so it works well. No issues with any websites either so far. 

[Darran_Lebas]

Fantastic news, just what I needed to hear .

[RS_Daniel]

Hi Amos, one question, do you know if it is planned to release this feature (categorization with verified SNI) for gaia embedded? 

[HeikoAnkenbrand]

I think SNI is full supported with R80.30. 

[HeikoAnkenbrand]

R80.30 SSL Inspection:

CUT R80.30 readme>>>

Server Name Indications (SNI)
- Improved TLS implementation for TLS Inspection and categorization.
- Next Generation Bypass - TLS inspection based on Verified Subject Name.

<<<CUT

[PhoneBoy]

It probably won't happen until an R80.x version of SMB firmware is available.