Re: [squid-users] Multiple-Choice chain proxies, preferably over authenticated HTTPS

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 05 Aug 2011 14:37:52 +1200

On 05/08/11 05:23, Hakim Moore wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Howdy all,
>
> I'm trying to make squid into a form of redirect,

Wonderful. Yet another definition of "redirect", this time to mean "proxy".

So you are setting up squid to be a form of proxy. Good. That is what
squid _is_.

> such that I can point
> portable firefox and portable thunderbird at it as a proxy and have all
> communications securely routed into the appropriate locally-run (well,

That is not possible. Only HTTP communications can pass through Squid
(full name: "Squid HTTP proxy"). You want a SOCKS proxy or tunnel relay
for generic protocol proxying.

Thunderbird HTTP proxy settings are for when it fetches web pages to
display pretending they are an email. The real email just contains
instructions on where to load the web page bits from and is not sent
through Squid.

> local to the server squid's running on) proxy. The goal is to have most
> URLs and all .onion go into localhost:8118, clear HTTP .i2p urls go
> through localhost:4444, HTTPS .i2p urls into 4445 and local urls be

There are two huge problems there.

First is that not all URLs are valid in HTTP. I'm not sure about onion
and i2p URLs.

Secondly this can only be done if your software agent is capable of
mapping the URLs protocol scheme into http:// or https:// protocol
schemes for the hop(s) through Squid.

I already mentioned Thunderbird is unable to map email (SMTP) message
URLs into HTTP protocol. SMTP and HTTP are polar opposites from
direction of traffic flow. The proxy I prefer to use for SMTP is postfix.

> directly sent to the local address. Also, DNS for all proxied URLs
> should go through the relevant proxy. So, as examples:
>
> http://blah.com/blah => 127.0.0.1:8118
> https://blah.com/blah => 127.0.0.1:8118
> http://blah.onion => 127.0.0.1:8118
> http://blah.i2p => 127.0.0.1:4444
> https://blah.i2p => 127.0.0.1:4445
> http://127.0.0.1:7660 (I2P mail tunnel) => Direct
>
> I hope to eventually run this over authenticated HTTPS, such that the
> communications and authentication are encrypted between me and Squid,
> and such that only I can do it. Feel free to point me at a whole bunch
> of guides. I just can't seem to find the right information on how to
> make this happen. Here's my current (and obviously insufficient)
> squid.conf:
>
> #
> # Recommended minimum configuration:
> #
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32 ::1
> acl to_localhost dstdomain localhost

NP: to_localhost is a carefully crafted ACL to protect against malicious
attacks accessing the localhost NIC.
   acl to_locahost dst 127.0.0.1/8 0.0.0.0/32 ::1

I suggest you leave that as it was. The .local domain space is RFC
assigned for safe use as TLD in site-local domain names.

> acl to_TOR dstdom_regex -i \.onion
> acl to_I2P dstdom_regex -i \.i2p

see dstdomain ACL syntax for wildcards. Drop the regex.

<snip>
>
> # Example rule allowing access from your local networks.
> # Adapt localnet in the ACL section to list your (internal) IP networks
> # from where browsing should be allowed
> http_access allow localhost
> http_access allow all

Terrible.

What is the intention with this?

>
> # And finally deny all other access to this proxy
> http_access deny all
>
> # Squid normally listens to port 3128
> http_port 3128
>
> always_direct allow to_localhost
> always_direct deny !to_localhost

  ... and yet "http_access deny to_localhost"

"direct" does not mean what you seem to think it does.

direct means direct OUT of squid; client->squid->origin instead if
indirect through a peer; client->squid->peer->origin

> cache_peer tor.proxy parent 8118 0 default no-query no-digest
> no-netdb-exchange
> cache_peer i2p.proxy parent 4444 0 default no-query no-digest
> no-netdb-exchange
> cache_peer i2ps.proxy parent 4445 0 default no-query no-digest
> no-netdb-exchange
> cache_peer_access i2p.proxy allow to_I2P !to_SSL
> cache_peer_access i2ps.proxy allow to_I2P to_SSL
> cache_peer_access tor.proxy allow all
>
> # The following settings are helpful in removing some sensitive
> # HTTP headers which could divulge unwanted information:
> #
> header_access From deny all
> header_access Referer deny all
> header_access Server deny all
> header_access User-Agent deny all
> header_access WWW-Authenticate deny all
> header_access Link deny all
>
> # We recommend you to use at least the following line.
> hierarchy_stoplist cgi-bin ?
>
> # Uncomment and adjust the following to add a disk cache directory.
> #cache_dir ufs /var/cache/squid 256 16 256
>
> # Leave coredumps in the first cache dir
> coredump_dir /var/cache/squid
>
> # Add any of your own refresh_pattern entries above these.
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
>

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.14
   Beta testers wanted for 3.2.0.10
Received on Fri Aug 05 2011 - 02:38:04 MDT

This archive was generated by hypermail 2.2.0 : Fri Aug 05 2011 - 12:00:01 MDT