Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
WAI_KIT_LAO
Participant

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

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?

 

31 Replies
William_Chang
Participant

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.

0 Kudos
PhoneBoy
Admin
Admin

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. 

0 Kudos
Hugo_vd_Kooij
Advisor

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.

<< We make miracles happen while you wait. The impossible jobs take just a wee bit longer. >>
0 Kudos
WAI_KIT_LAO
Participant

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.

0 Kudos
Albert_Wilkes
Collaborator

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... 

0 Kudos
D_W
Advisor

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
Employee
Employee

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
Advisor

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?

0 Kudos
Amos_Reiss
Employee
Employee

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
Participant

It's good to hear that improvement from you.

Does the fix work for R77.30?

0 Kudos
Amos_Reiss
Employee
Employee

No, only R80.10 and later versions.

0 Kudos
Paul_Hagyard
Advisor

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

0 Kudos
Amos_Reiss
Employee
Employee

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

0 Kudos
Carey_Page-Sinc
Explorer

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

0 Kudos
Amos_Reiss
Employee
Employee

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

0 Kudos
Robert_Gilbert
Participant
Participant

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? 

0 Kudos
Amos_Reiss
Employee
Employee

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

Thanks

Amos

0 Kudos
Darran_Lebas
Participant

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? 

0 Kudos
Robert_Gilbert
Participant
Participant

Hi,

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

Robert_Gilbert
Participant
Participant

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. 

0 Kudos
Darran_Lebas
Participant

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

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

0 Kudos
Robert_Gilbert
Participant
Participant

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
Participant

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
Participant
Participant

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
Participant

Fantastic news, just what I needed to hear Smiley Happy.

RS_Daniel
Advisor

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

HeikoAnkenbrand
Champion Champion
Champion

I think SNI is full supported with R80.30. 

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
HeikoAnkenbrand
Champion Champion
Champion

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

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
PhoneBoy
Admin
Admin

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

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events