Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Rob_McLoughlin
Participant
Jump to solution

URL Filtering - Block Category Allow Specific URLs

We block the YouTube category within the organization but one particular URL some users go to has a "www.youtube.com/embed/<unique identifier to video>" somewhere at the start of the page so users never fully can load the page.  Access Control blocks the YouTube but since their embedded the page starts to load and fails with no block message (either the flash or html 5 screen just spins on the loading graphic).  I'm trying to just exclude these particular youtube links but not sure if it's possible.  I have a URL Exclusion custom application url list where I place all my exceptions.  Putting in the "www.youtube.com/embed/<unique identifier to video>" doesn't work.  I'm used to just putting in *domain.com in for exceptions and not specific URL strings.  Any suggestions or not possible what I'm trying to accomplish?

I am utilizing HTTPS Inspection and I'm on R80.10 JHF take 24

0 Kudos
1 Solution

Accepted Solutions
Rob_McLoughlin
Participant

Just wanted to follow back up on this.  After I posted this the good folks at R&D reached out to me to help me troubleshoot the issue.  It appears my issue is due to the fact that when HTTPS Inspection bypass is enabled for anything Google (Search Engines / Portals, Custom Application with *google.com, etc) it also excludes YouTube inspection since the DN of the certificate is google.com.  In my case I needed YouTube to be inspected (not excluded) to categorize it properly and because I was already excluding *google.com I was just spinning in circles with my attempts.  I was told they acknowledge this as a concern (with YouTube being seen as google.com) and it's a high priority to fix.  For now I was able to finagle a solution that works for us until the fix is put in.

View solution in original post

0 Kudos
2 Replies
Rob_McLoughlin
Participant

Just wanted to follow back up on this.  After I posted this the good folks at R&D reached out to me to help me troubleshoot the issue.  It appears my issue is due to the fact that when HTTPS Inspection bypass is enabled for anything Google (Search Engines / Portals, Custom Application with *google.com, etc) it also excludes YouTube inspection since the DN of the certificate is google.com.  In my case I needed YouTube to be inspected (not excluded) to categorize it properly and because I was already excluding *google.com I was just spinning in circles with my attempts.  I was told they acknowledge this as a concern (with YouTube being seen as google.com) and it's a high priority to fix.  For now I was able to finagle a solution that works for us until the fix is put in.

0 Kudos
PhoneBoy
Admin
Admin

Thanks for following up and apologies this didn't get a public response.

I'm glad R&D reached out to you on the backend.

What I can do is provide a little more color on the situation.

Hosting companies have using one server and one IP address to host many different websites or properties for a couple of decades now. 

The way the server differentiates between the various properties is the HTTP Host header. 

Based on this value, the server will serve up the appropriate content. 

Obviously, this creates a problem when you add HTTPS to the mix when you need to validate the site you are connecting to before you pass any real data (including an HTTP Header).

Up until fairly recently, you had to dedicate an IP address to each property as you can use a single certificate per reachable IP address.

This became problematic to implement as the supply of IPv4 addresses exhausted. 

An SSL/TLS certificate has a fairly flexible structure that's easy to extend.

One of the ways it was extended was the SubjectAltName field.

This essentially is a way of saying "this certificate is also valid for these sites" (whereas the DN field is the primary identity).

Many sites (including Google) do this, including this very community site. 

The problem is: the certificate alone doesn't tell you which property you're actually accessing.

Which is kind of important for the webserver to know so the correct configuration and document root is applied to the connection.

An extension to the TLS protocol called SNI (Server Name Indication) tries to solve that.

The client signals as part of the TLS negotiation what site it is trying to access.

The problem with SNI is that it's sent in the clear, making it trivial to spoof.

This makes SNI not really a good candidate to make security decisions based off of.

This is why, on Check Point Security Gateways, for some applications and sites to be properly detected, HTTPS Inspection must be enabled.

R&D is working on addressing this limitation, as you noted above.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events