Search squid archive

Re: Transparent proxy with HTTPS on freebsd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux