2
1
I've set up privoxy on my router with OpenWRT. The proxy seems to work well as I am able to surf with my traffic going through it.
I tried setting a minimal example of blocking with only one domain in a block rule:
{+block {Too bad my friend...No facebook for you}}
www.facebook.com
This rule can be found under the file tinyblock.action, which I include in my config in /etc/config/privoxy. The enable-blocks option is set to 1. However, when I try to access facebook, the proxy doesn't block anything...
Any idea on that matter?
As answered by @MariusMatutiae, there's a problem with https filtering. I did a bit of research and the privoxy documentation says explicitly:
4.15. How can Privoxy filter Secure (HTTPS) URLs?
Since secure HTTP connections are encrypted SSL sessions between your browser and the secure site, and are meant to be reliably secure, there is little that Privoxy can do but hand the raw gibberish data though from one end to the other unprocessed.
The only exception to this is blocking by host patterns, as the client needs to tell Privoxy the name of the remote server, so that Privoxy can establish the connection. If that name matches a host-only pattern, the connection will be blocked.
As far as ad blocking is concerned, this is less of a restriction than it may seem, since ad sources are often identifiable by the host name, and often the banners to be placed in an encrypted page come unencrypted nonetheless for efficiency reasons, which exposes them to the full power of Privoxy's ad blocking.
"Content cookies" (those that are embedded in the actual HTML or JS page content, see filter{content-cookies}), in an SSL transaction will be impossible to block under these conditions. Fortunately, this does not seem to be a very common scenario since most cookies come by traditional means.
But anyhow, I never show facebook showing up on my logs...
Rerito
Posted 2015-11-22T13:29:18.873
Reputation: 123
"often the banners to be placed in an encrypted page come unencrypted nonetheless for efficiency reasons".... every modern browser I've seen warns about this, because of the side channel leakage (the HTTPS URL is visible in Referer, cookies.... and that doesn't even get into the problems of script injection via the insecure elements) – Ben Voigt – 2015-11-22T14:01:58.207
@BenVoigt That's not the problem at hand. Here, if I understand the doc correctly, the block action should work even though the traffic is in HTTPS because I use a host-pattern. – Rerito – 2015-11-22T14:05:43.207
No, that's just commentary on the technical inaccuracy of the documentation you're quoting. Your actual problem is probably that your system isn't configured to send HTTPS traffic to the proxy in the first place. Are you using explicit proxy configuration (in the browser), or transparent redirect via iptables rules? – Ben Voigt – 2015-11-22T14:09:14.853
@BenVoigt A chance you asked... So far I'm just in a testing setup so I apply proxy settings on my machine. Once I'll have validated the desired behavior I'll set iptables rules on the router to redirect the traffic through the proxy. I noticed after checking I didn't set up the https proxy... When I do though, I get the
ERR_TUNNEL_CONNECTION_FAILEDfrom chrome – Rerito – 2015-11-22T14:14:47.540@BenVoigt After that last remark, I tried accessing other pages through https and everything went alright. I deduce from this that privoxy does it job. It just doesn't show the usual blocked page (maybe because it cannot edit the request content since it's encrypted). I'ld be happy to accept an answer from your comment as you made me notice my mistake :) – Rerito – 2015-11-22T14:28:12.483
you also can't have a space between {+block and the comment start { – Matthew Lock – 2016-06-26T02:25:12.173