Re: [squid-users] Transparent proxy with HTTPS on freebsd

Gavin McCullagh wrote:
> Hi,
>
> On Wed, 06 May 2009, Matus UHLAR - fantomas wrote:
>
>> On 04.05.09 22:35, Gavin McCullagh wrote:
>>> Would you care to substantiate that in a bit more detail?
>> Making clients think they connect to the destination server when they do
>> not, breaks many things. It disables authentication, causes some TCP
>> problems (pmtu discovery?)...
>
> Many thanks for the extra info.
>
> Disabling authentication is unfortunate, but anyone managing a network and
> proxy server who decides to use transparent proxying necessarily makes the
> decision not to use authentication.
>
> PMTU discovery is not something I had thought about I must say. At a guess
> the main issue is that if a router between client and proxy sends a
> "datagram too big" to the proxy, it'll have the IP of the upstream host on
> it and will not get to the proxy. In our case (where the MTU is
> consistent across the whole path), that won't be an issue but I can see how
> it could be. I guess you could turn off PMTU disovery on the proxy to
> solve this, though that's a bit of a sledgehammer.
>
> There would also be an ambiguous MTU for the client (ie that of the
> client<->proxy and the client<->server) which would depend on what port the
> client was connecting on (eg it could mix http and https). I'd guess,
> perhaps wrongly (and assuming the icmps are not blocked) the client should
> just end up with the minimum MTU for both paths?

Should being the operative word. Though the trouble case occurs when the
proxy tries to send a MTU too big to the client. You see the client
machine has no knowledge that a TCP link to proxy is open at all and
disregards the packet. Thus there are problems when the MTU between an
intercepting proxy is smaller than the MTU between client and server
directly or proxy and server.

The workaround for this is to sit the proxy as the gateway router or
direct intermediary. Which may or may not be an option under your packet
loads.

Additional issues occur when hierarchies of proxies (sometimes needed to
cope with ISP level loads) move the actual link between proxy->server
far away.

>
>> That's bad, luckily many browsers can turn on autodetection and use it when
>> available.
>
> You mean the browser downloading http://wpad.<domain>/wpad.dat? This has
> been pretty flakey in our experience. In most cases you seem to have to
> turn it on explicitly which is a huge pain as students don't know how.

wpad.<domain>/wpad.dat, http://wpad/wpad.dat, http://wpad.<your
TLD>/wpad.dat, whatever URL you configure in DHCP.

Enabling them all is a good idea, and globally having students set "auto
detect" is a good thing. Flakey or not.
If it works you have none of the issues of interception. If not you have
interception as a last resort backup.

>
>> Well, I always call intercepting a thing you should do in "last resort" and
>> all troubles caused by the interception should be pointed as client errors.
>
> Fair enough.
>
>> Yes, if you need, keep that there, but I hope you didn't stop providing WPAD
>> for anyone who supports it.
>
> We still provide it alright, though I don't think it gets used much. One
> of our networks, where we require authentication still use it all the time.
>
> Gavin
>

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14
   Current Beta Squid 3.1.0.7