Re: protocol support for intercepting proxies

Travis Snoozy wrote:
> I'm going to try and be terse today. :)
>   
OK, me too.

> <snip>
> See the friendly notice at http://www.wpad.com/ for why this was a
> REALLY bad idea. He could be hijacking a whole lotta browsers right
> now, if he weren't so nice.
>
>   
actually I only ever saw lookups for "wpad", none for "wpad.com".  I 
guess there was a time where DNS resolvers were pretty gung-ho about 
automatically appending local domain suffices to all lookups.  actually 
they still are.  But yeah, DNS is wide open to abuse like this, since 
you never know where the record will come back from.

And if that page is anything to go by, we can probably expect that a LOT 
of browsers are configured not to use proxy auto configuration.  
Typically upgrades to the browser honour previous settings like this, so 
we have a sizeable migration issue if we want to push WPAD out due to 
control being client-side.

> http://www.wpad.com/draft-ietf-wrec-wpad-01.txt states that option 252
> must be supported by clients. Yeah, yeah; not a formal spec, but if
> you use part of it, you're in for the whole nine yards.
>   
It also suggests that browsers writers write minimal implementations of 
DHCP clients into themselves.  I see a few problems with this, firstly 
that many DHCP servers will only send replies back on port 68, which the 
browser may not be able to reliably bind to (since the OS DHCP client 
already is).  Sure, you can disable binding conflicts, but in my 
experience you don't reliably receive the data.

Plus then you get a zillion different implementations of DHCP clients in 
various states of bugginess.  Sure, the nice engineering solution to 
this is to require authors of DHCP clients to put in APIs to allow 
clients to get data.  Having written a DHCP server though, I can attest 
that it is probably the ugliest protocol, closely followed by DNS then 
probably IMAP (all of which I have written servers for, so have a small 
amount of experience with).

All the chain of WPAD query types must add up to a lot of timeouts :)  
If you take your laptop to a network that doesn't implement ANY WPAD 
option, you'll be waiting a while.

<snip>

I thought of one more reason for interception: To force use of the proxy.

If you're an admin and you have a gateway and firewall and proxy, what 
are your options if you want to force everyone through the proxy for say 
port 80?

You can block access to port 80 through the firewall except for the 
proxy.  You can enable option 252 in your DHCP server, enable WPAD in 
your DNS server etc etc.

However, the client can circumvent all of this.  By manually setting 
their browser not to use a proxy, and not to use WPAD, then they will 
try connecting directly out on port 80.  Ok, so you're blocking this, 
what does the client see?  Connection timeout.  Not very friendly.  
Results in calls to IT department.

In order for a sys admin to be able to send any meaningful response back 
to the user and UA, HTTP protocol must be used, and this can only be 
done if you intercept/divert the connection to something that will take 
the connection, and talk HTTP.

Even if the only purpose on the planet for an intercepting proxy was to 
send a page back to a client saying "smack! naughty you must use a 
proxy", then that is still a valid and useful purpose.   A slightly more 
helpful proxy could even provide a page documenting how to turn on proxy 
auto-config.  If you take that line to its logical conclusion, the 
client will automatically set the proxy to use.  This is what the 
customers will be asking for.  They will say "I don't care, just solve 
the security issues, why keep giving me more tasks to do when you can 
get the software to do it for me".  I personally believe that in certain 
cases, the security issues can be addressed.  I don't think anyone here 
is proposing that it's impossible in all cases to do this securely.


Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 19 June 2007 02:38:13 UTC