Youtube SSL

[AdamB]

Whenever I just turn on tarpit for youtube it seems to work fine. All youtube is blocked and I can't access the site.

Note: if you are using IPv6 its not gonna matter what you do. IPv6 is not yet scanned by the apps.

There is no way google could use a non-youtube cert because then the browser would not accept it.
I would just use tcpdump and see whats going on.

Maybe I don't recall the details correctly, but that was the response from your tech's, feel free to look back at my old tickets and look it over.

Looking over the ticket and some of it is starting to come back to me (#5973)

[yotefn]

I would post my logs but can't get them to render properly in the forum.

[yotefn]

Alright, I resorted to a JPG to show what's happening. This is getting frustrating. Setting YOUTUBE to tarpit is ineffective.
Here is the log from Application Control, when accessing https://www.youtube.com, in two JPGs.
UT1.jpgUT2.jpg

[dmorris]

I would record the packets with tcpdump
tcpdump -i eth0 -n "port 443" -s 0 -w packet.trace

open the dump file up with wireshark and look at the sessions.

If you checked block youtube, it should only block youtube, not the associated sessions to doubleclick and google etc.

Thing to check for: SNI information, IPv6, certification, your browser cache.
You should also try tarpit, as many browsers will retry reset connections without SNI information.

Everything in your screenshot looks correct. It even shows the blocked youtube sessions.

[yotefn]

I'll get to this later...

A full Youtube page displays, even though the Youtube sessions are blocked.

I'm not using IPv6 at all on my network. Youtube is set to TARPIT. SNI information doesn't appear in Web Filter, I'll look at the packets when I get a chance.

[yotefn]

For all of you people out there fighting with this problem, I've discovered a work around that is really inconvenient but it works. BTW, Untangle phone support has confirmed that this is an issue and google based domains resist blocking. This includes Gmail and Youtube.

1. Run NSLOOKUPs for the domains you want to block HTTPS traffic for.
2. Add static DNS entries to your internal DNS servers that are correct for those domains. (Just pick one out of the list that may appear)
3. Add those IP's to the blocked sites list on the web filter, or through the firewall application block port 443, if you want to allow HTTP access.

NOTE: This suggestion can wreak havoc on your network if you don't maintain properly... If a DNS entry should change things won't work properly.

But this does leave me with a big question: Aren't we paying Zvelo to be doing this work for us? They should be categorizing the google domain IPs and not just listing them as Miscellaneous.

[Oatman]

Zvelo really sucks at updating its database. They rely primary on user based submissions and although they say that they get new sites down within hours. Its not true. I know some sites that still haven't been blocked in months and if I report them they do nothing to change it.

[yotefn]

I haven't found this to be the case. I think Zvelo is doing pretty well at a monumental task, and they update things I enter via test-a-site quite quickly.

I did contact them about this and received the following response:

Hello. Thank you for contacting zvelo.



zvelo tracks and updates lists of various IP address ranges within the zveloDB® for Google, where we do in fact default to the category of “miscellaneous”. The reason for this is that Google uses the IP addresses within their ranges for various dynamic purposes. All of their IPs can serve up any content (search, gmail, maps, calendar, groups, etc...) at any given time. The content returned depends on the URL used in the request.



As an example, you could have two user URL requests, where one types "www.google.com" in their browser and another types "gmail.google.com"

at the same time. The DNS lookups for those two different hosts could actually return the exact same IP address, but the first one will get the search page and the second will get the gmail login page.



Since the IP addresses of Google can serve up any content (e.g. search, gmail, maps, calendar, groups, etc...) zvelo cannot assign a category that will stay static / correct, hence we made an internal decision to go with the default category of Miscellaneous.



Although this is not the desired outcome in regards to your request, we have taken the action item to see if we can use another, more granular category (such as CDN - content distribution network) in the future.



May I inquire if there is a common IP address (or smaller series of IP addresses) that are particularly problematic that can be further analyzed by our team for your specific need?





Regards,

I've confirmed that they are right. That is how I arrived at the workaround that I posted above.