Re: New issue: Need for an HTTP request method registry

Lisa Dusseault wrote:
> +1.  I've never understood why, in the worst case, an intermediary 
> couldn't have a configuration file or admin UI that allowed humans to 
> add or remove whitelisted or blacklisted method names.  It seems 
> extraordinarily backwards, especially nearly 10 years after WebDAV 
> first appeared on the 'Net, to require software updates to handle new 
> methods!
>
> Lisa

One could also argue that a security product that allowed unknown 
methods through was also "backwards".  Proxies with a security focus are 
about control.  To control, first one must understand.  Therefore in 
order to provide an effective security product, each controlled method 
must be firstly recognised then understood (for finer-grained control) 
by the proxy.  Recognition of a method in a product can be configurable, 
but understanding has to be built-in.

The concept of allowing unknown methods without that being an explicit 
wish of the administrator is incongruous.  In order for that to be an 
explicit wish, the administrator needs to understand its implications.  
So even if we add an admin control about whether to allow unknown 
methods or not, (or worse still allowing the admin to set allow/deny on 
any entered method name) trying to explain the meaning of such a control 
to users is costly.  What do we choose for the default setting of such a 
control?  The seemingly-humble default setting has wide-reaching 
implications, knowing that 99% of people never touch it, or ever bother 
to figure out what it means.  Choose the wrong value and there's 
trouble.  Allowing all unknown methods would seem to be the safe option 
from a tech-support point of view, but is unpalatable from a security POV.

Also the semantics of all methods aren't exactly the same.  CONNECT and 
TRACE for example pose separate kinds of problems for proxies.  Are we 
saying that any new method must work the same way as the old ones so 
that they can go through a proxy?  That seems to be a fairly significant 
limitation on the scope of future expansion if you ask me.  For instance 
a method to pre-negotiate transfer of a large message body from a client 
to a server wouldn't fit into this category (but I see more evidence of 
a requirement for it every day, and not only related to "broken" NTLM).

In the end, let's just accept that the existence of proxies that do only 
allow a hard-coded set of methods is proof enough that it is possible to 
create such a proxy, and rather than judging, we could look to see why 
it is that it happened in the first place.  There are often many things 
in a spec that an implementor decides (rightly or wrongly) are incorrect 
or undesired behaviour.  SMTP for instance is full of them.  The 
implementor consoles themselves with the rationale that "this spec was 
written back in the day when the Internet was a big happy family, with 
no regard to security - things are different now", and that gives them 
the mandate (in their mind) to do whatever they wish. So it's not just a 
matter of blindly following the spec.  There are often conflicting 
pressures.

Someone that studies complexity would look at this and laugh, as it's an 
obvious complexity-related problem.  HTTP isn't compartmentalised 
(unlike layered protocol systems), so complexity becomes an 
ever-increasing issue.  The rate of increase in interdependencies is 
like geometric.

Anyway, I wish I had an answer for how to get people to read 
documentation at all let alone properly.  It goes against human nature 
it seems - like trying to fight the weather. In the end, the longer the 
document, and the less familiar language it uses, and the more 
cross-referencing that is required, the less likely it will be 
completely successful in its mission of imparting its content to the 
reader. 

At least thanks to the people on this list I know we need to make some 
changes (not quite sure what though) - appreciate that thanks. 

Regards

Adrien

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

Received on Tuesday, 7 August 2007 22:15:21 UTC