Re: [squid-users] how does squid work as a transparent proxy?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 8 Jul 2008 15:00:27 +1200 (NZST)

> Hello,
>
> I am new to Squid and I'd like to ask a question about its internal
> workings when operating as a transparent proxy.
>
> I saw that one configure the host kernel with an iptables rule in the
> nat table with the REDIRECT target to match packets destined to some
> port (e.g 80) and redirect them to some other port on the local host
> (e.g 3128). From what I understand, when iptables matches a packet
> against this rule, it overwrites the packet's destination IP address and
> TCP port with, respectively, the local IP address and 3128.
>
> How does Squid (e.g in the case of an HTTP request) know the IP address
> of the original web server that the packet was destined to?

iptables(kernel) keeps an internal record of these changes, in case there
is any returning traffic to deal with.
Squid has code which asks iptables(kernel) what the original destination was.

> For
> example, if the GET-ed object doesn't exist in cache, how does Squid
> know where to connect() to and request the object?

Squid processes the request and located the domain name being requested.
Clients place it in Host: header of their request.

> I tried looking at
> the source code and it looks like in some cases Squid might be parsing
> the domain name from the GET request and using a DNS lookup on this
> domain name to determine the IP address. Is this always the case?

Yes. There are serious security problems with any other method of
handling, so don't even ask us to change it ;-).

>
> If yes, does Squid do something similar in the case of other supported
> protocols - SSL, gopher?

gopher, ftp, whois, https; are only supported if the client sends an HTTP
URL request through a known proxy. Transparent interception of them is not
supported.

HTTPS, has a sslBump feature in the upcoming 3.1 which allows some small
degree of interception, but the nature of SSL makes the proxy visible to
the client as a possible middle-ware attack (which it actually is).

Amos
Received on Tue Jul 08 2008 - 03:00:32 MDT

This archive was generated by hypermail 2.2.0 : Tue Jul 08 2008 - 12:00:04 MDT