[squid-users] can't block streaming

[Amos Jeffries]

On 01/11/17 21:54, Vacheslav wrote:
> Thanks for your time,
> 
> -----Original Message-----
> From: Amos Jeffries
> Sent: Tuesday, October 31, 2017 5:45 PM
> 
> On 31/10/17 22:05, Vacheslav wrote:
>> Peace,
>>
>> I tired searching and debugging but I couldn’t find a solution,
>> whatever I do youtube keeps working.
>>
>> Here is my configuration:
> ...
>> # Media Streams
>>
>> ## MediaPlayer MMS Protocol
>>
>> acl media rep_mime_type mms
>>
>> acl mediapr url_regex dvrplayer mediastream ^mms://
>>
>> ## (Squid does not yet handle the URI as a known proto type.)
> 
>> Unsupported URI schemes should result in the client receiving an HTTP error page instead of Squid handling the traffic.
> 
>> Which also explains your problems: the Browser is either not using the proxy at all for this traffic, or sending the traffic through a CONNECT tunnel that is allowed to be created for other reasons.
> 
> Well I tried unchecking automatically detect proxy settings. There are 2 network cards on the squid, one with a gateway, the same  is used as the proxy ip port 3128 and youtube is not in the bypass proxylist. I tried using opera, the same result.

Things like YT do not have to be on any bypass list to avoid the proxy. 
It just has to have a URL scheme for some protocol the browser detects 
as not able to go through the HTTP-only proxy. eg "mms:"

Since mms:// means a non-HTTP protocol and it is not commonly supported 
by HTTP proxies, the browsers usually send it directly to the mms 
protocol port(s) AFAIK.


> What do you mean by a connect tunnel?

Things like this:

"
  CONNECT r1---sn-ntqe6n76.googlevideo.com:443 HTTP/1.1

  ... non-HTTP data stream.
"

Which tells Squid to open a TCP connection to the named server and port. 
That is how a YouTube video I'm watching right now is currently going 
through a test Squid. The browser of course shows it as a GET request 
for some https: URI, but the proxy only sees that CONNECT.

To see what is inside that particular port 443 tunnel one has to use 
SSL_Bump feature to decrypt the HTTPS protocol that is supposed to be on 
that port.


> ...
> 
>> # We strongly recommend the following be uncommented to protect
>> innocent
>>
>> # web applications running on the proxy server who think the only
>>
>> # one who can access services on "localhost" is a local user
>>
>> #http_access deny to_localhost
>>
>> # Deny all blocked extension
>>
>> error_directory /usr/share/squid/errors/en
>>
>> deny_info ERR_BLOCKED_FILES blockfiles
>>
>> http_access deny blockfiles
>>
>> #
>>
>> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
>>
> 
>> Please read the above line, and consider all the custom rules you placed above it.
> I moved the below text to under
> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> 
> http_access deny mediapr
> http_access deny mediapr1
> http_access deny mediapr2
> http_access deny mediapr3
> http_reply_access deny media
> ...
>>
>> #url_rewrite_program /usr/sbin/squidGuard
>>
>> #url_rewrite_children 5
>>
>> #debug_options ALL,1 33,2 28,9
>>
>> And where must I place the before last 2 lines in order for squid
>> guard to work?
>>
> 
>> Right there where they are in your config will do.
> 
>> What do you expect SquidGuard to do?
> 
> At first, I thought squid guard is needed to block file extension, then I discovered that it blocks urls so it is not a bad idea to block porn sites and porn search terms.

Ah, I see. Well, if you are new to it I advise to try using squid.conf 
ACLs first. Sending things to helpers is quite I/O and memory intensive 
and most of what SG does can be done better by modern Squid.

Also, SquidGuard specifically is very outdated software and no longer 
maintained. If you have to do access control in a helper at all it is 
better to use the external_acl_type interface and other helpers that 
meet the more specific need.


> 
>> If Squid itself cannot identify any URLs with "mms://" scheme there is no hope of SG being passed the non-existent URLs.
> 
> This I didn't digest!
> 

See above with the CONNECT example. *If* the request is actually going 
through the proxy, the URI as far as Squid can see would be something 
like "r1---sn-ntqe6n76.googlevideo.com:443", or maybe just a raw-IP and 
port.

So what Squid can pass the URI helper is only that origin-form URI, not 
the encrypted (if HTTPS) or tunneled (if non-HTTP/HTTPS) absolute-URI 
stuff where the scheme is.

Amos