[squid-users] I can't block streaming !!!

Amos Jeffries squid3 at treenet.co.nz
Wed Jan 20 04:22:20 UTC 2016


On 20/01/2016 5:16 a.m., Aismel wrote:
> Hi guys
> 
> Thx for your replys
> I want to block all streaming video and music....
> 
> I'm testing with Youtube this code but don't work and try
> http://wiki.squid-cache.org/KnowledgeBase/Block%20QUIC%20protocol
> 

Notice how QUIC protocol is a protocol and YouTube is a website - two
different things.

> but nothing happened... maybe I'm doing something wrong with iptable, juts
> copy and paste the example...
> 

You now have three problems; youtube not being blocked, the idea in your
head, and the cut-n-paste config.


You need to understand what that config does in order to make the
changes necessary to make it actually work in your network. The intro
text at the top of the page is supposed to explain that for you.

What it does not mention is that the config following is in fact partial
config snippets for 8 separate and often unrelated pieces of hardware.

The important thing to know is that all it does is block ports UDP/80
and UDP/443 in your firewall(s). That is all.

If you are playing with networking you should know how to do that for
your own systems without cut-n-paste from our wiki.


> So I need understand first to all see the all picture because for one side
> some user say something and by other hand another thing and really I don't
> think this issue is a some important... pls enlighten me
> 

At this point you are so confused what you think no longer matters. Its
wrong in some ways.

So stop, pause. Lets see how much of my analysis matches your
understanding, and where you might be diverging.


> 
> My SQUID Log tell this when a user open Youtube
> 

By "youtube" here you are meaning the web page text (HTML) - not
anything even remotely resembling a stream.

> 
> 1453231046.695  12165 172.16.1.50 TCP_MISS/301 471 GET http://youtube.com/
> someuser DIRECT/74.125.196.91 text/html
> 
> 1453231059.561  12654 172.16.1.50 TCP_MISS/301 830 GET
> http://www.youtube.com/ someuser DIRECT/74.125.196.93 text/html
> 

Then it stops being "youtube" ... and starts being "google".

This is background traffic setting up TLS to Google:

> 1453231064.593   2239 172.16.1.50 TCP_MISS/000 0 POST
> http://clients1.google.com/ocsp someuser DIRECT/clients1.google.com -
> 
> 1453231079.463   1805 172.16.1.50 TCP_MISS/000 0 POST
> http://clients1.google.com/ocsp someuser DIRECT/74.125.196.101 -
> 
> 1453231080.243   2759 172.16.1.50 TCP_MISS/000 0 POST
> http://clients1.google.com/ocsp someuser DIRECT/74.125.196.101 -
> 
> 1453231126.749    620 172.16.1.50 TCP_MISS/200 1012 POST
> http://clients1.google.com/ocsp someuser DIRECT/74.125.196.102
> application/ocsp-response
> 
> 1453231126.784    470 172.16.1.50 TCP_MISS/200 1012 POST
> http://clients1.google.com/ocsp someuser DIRECT/74.125.196.102
> application/ocsp-response
> 

This is advertising, from various of the Google owned advertising outlets:

> 1453231140.519  64309 172.16.1.50 TCP_MISS/200 11581 CONNECT
> pubads.g.doubleclick.net:443 someuser DIRECT/74.125.196.155 -
> 
> 1453231141.600  66654 172.16.1.50 TCP_MISS/200 37205 CONNECT
> yt3.ggpht.com:443 someuser DIRECT/74.125.196.132 -
> 
> 1453231154.532  61052 172.16.1.50 TCP_MISS/200 4714 CONNECT
> gg.google.com:443 someuser DIRECT/74.125.196.102 -
> 
> 1453231163.576  60340 172.16.1.50 TCP_MISS/200 5079 CONNECT
> googleads.g.doubleclick.net:443 someuser DIRECT/173.194.37.77 -


This is "youtube" again, images for the page from earlier:

> 
> 1453231163.564  88718 172.16.1.50 TCP_MISS/200 365630 CONNECT
> i.ytimg.com:443 someuser DIRECT/74.125.196.101 -
> 
> 1453231164.565 104857 172.16.1.50 TCP_MISS/200 47731 CONNECT
> www.youtube.com:443 someuser DIRECT/74.125.196.93 -
> 
> 1453231169.599 103517 172.16.1.50 TCP_MISS/200 376650 CONNECT
> s.ytimg.com:443 someuser DIRECT/74.125.196.139 -
> 

This is google login happening:

> 1453231185.663  60424 172.16.1.50 TCP_MISS/200 4870 CONNECT
> accounts.google.com:443 someuser DIRECT/74.125.196.84 -
> 
> 1453231187.657  84365 172.16.1.50 TCP_MISS/200 121248 CONNECT
> apis.google.com:443 someuser DIRECT/74.125.196.100 -
> 
> 1453231187.669  60628 172.16.1.50 TCP_MISS/200 27795 CONNECT
> oauth.googleusercontent.com:443 someuser DIRECT/74.125.196.132 -
> 
> 1453231187.681  60639 172.16.1.50 TCP_MISS/200 8105 CONNECT
> ssl.gstatic.com:443 someuser DIRECT/74.125.196.94 -
> 
> 1453231188.673  63279 172.16.1.50 TCP_MISS/200 8763 CONNECT
> content.googleapis.com:443 someuser DIRECT/74.125.21.95 -
> 

So far it has taken a full 2 minutes to show the page. And these are
just the parts which finished so far. From experience there are maybe a
dozen more parts that are not listed here. D/L of the player scripts,
jQuery, the "please install Chrome" nagware, and some other spyware.

>  
> 
> I don't not if is necessary block the youtube page I only want to block when
> some user try to play a video... 
> 

The actual video AFAICT is not in that log section. Which means it is
either in a connection that is not yet finished according to that log
section, or bypassing the proxy.

If its a long duration CONNECT it could be still open when you went
looking for it. You need the video to have been fully stopped and
preferrably the page/tab closed as well to be sure everything is logged.


Bypassing the proxy is what QUIC is about. You can add those rules from
the wiki to block it at your firewall. But doing so is not a guarantee
even if you get them right - because it is just one possibility amongst
several for how the video is happening. When QUIC is blocked, one of the
others is used. You have to locate and block all of them.



Another nastier alternative is Alternate-Protocol headers in the HTTP.
They are how the browser is told to use QUIC. But it could be told to
use QUIC over unusual ports, or non-QUIC protocols as well. Stripping
the headers is needed to prevent this. That might mean decrypting the
CONNECT tunnels and processing the HTTPS requests from inside them.


The easy way out is to just reject/deny the youtube.com domain entirely
being accessed through the proxy. That blocks the HTML page that starts
the whole nasty sequence. Remember it? the very first two lines in your log.


Amos


More information about the squid-users mailing list