On 03/11/17 22:42, Vacheslav wrote:
-----Original Message-----
From: Amos Jeffries
Sent: Wednesday, November 1, 2017 3:52 PM
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.)
Unsupport> To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: can't block streaming
ed 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.
Well I tired switching the ip of the pc to one that can't do http and https at all without proxy. I tested it without proxy enabled and internet sites don't open, I switched the proxy back on and youtube works when it is forbidden.
That test is not conclusive enough I'm afraid. YouTube system is very
complex and requires about a dozen transactions to take place in order
to find the video content. Any one of those HTTP(S) responses may
reference a non-HTTP video type as being in use at the end of the chain
so your ACLs dont block it specifically.
That complexity might make it _seem_ easier to 'block' YT videos by
breaking the chain of transactions. But unfortunately you have to
isolate and block the right ones for that to happen without letting the
client do any failover behaviour it might be capable of. AND many of
them are buried inside encrypted tunnels nowdays.
So blocking one of Google service usually means blocking large areas, or
all, of their other services as well. Unless you want to go down the
MITM road and decrypt the HTTPS at the proxy - with limited success even
then thanks to the cert pinning Google does.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
