Re: RFC 3205 background (HTTPSubstrate-16)

Keith's points below are very strong points in favor of RFC 3205, and have
nothing to do with possible proxy rewriting of HTTP.  I think the
proxy issues are a bit of a distraction in this conversation; *any*
traffic is going to be susceptable to interception.

The thing I find appealing about these arguments is that they speak to the
operating system/application boundry issues.  Any serious architecture is
going to have to make recommendations as to what is a service of the
operating system, and what is an application that rides on top of those
services.

Rob

On Fri, 5 Apr 2002, Keith Moore wrote:

> > [...]
> > ] Addressing these in bullet item order, the definitions of "traditional
> > ] HTTP service" and  "new service" are not clear.  It is very difficult to
> > ] characterize HTTP traffic in a meaningful way since every URI is
> > ] potentially a "new service" in some fashion. Using the dataset referenced
> > ] doesn't follow the spirit of the World Wide Web and resources of many
> > ] types can co-exist in similar URI namespaces.
>
> The reason for the data-set rationale is that each server process forms a kind
> of trust boundary - it has permissions granted to it by the operating system,
> which affect the data (files) that the server can access.   Also, typically
> only one process can be listening for incoming connections on any particular
> port.  when there is a need for different services to access different sets
> of data which require different permissions, it is often easier and more
> secure to implement those services on separate server processes (and this
> implies separate ports) than to expect one process to securely implement all
> of those services without leaking information between one service and other.
> With the latter approach, the compromise of a single server potentially
> compromises all of the data that can be accessed by any of those services.
> Also, on many systems there is no way to say "process X has permission
> to access files owned by user A, B, C, F, H, Q, and Z" - either process X
> has permission to access files of one user, or those of all users.
>
> So it may be that the granularity of permissions on most operating systems
> doesn't "follow the spirit of the World Wide Web" but this language in
> 3205 was just trying to reflect that reality.  I don't think the web
> architecture should constrain people to put each permission domain on a
> separate host, or to assign multiple IP addresses per host, just so they
> can use port 80 for everything.  People can do that if they wish, of course,
> but I don't think the architecture should insist on it.  And there's no
> way I'm going to recommend that people run their web servers as root.
>
> > ] Utilization of dedicated ports to filter services on the Web
> > ] would not address all security issues and would be expensive in terms of
> > ] number of ports in use and enterprise support requirements.
>
> Certainly true, and I've never claimed that it would.  Ports are only
> a crude tool. They're not even close to a complete security solution,
> but they can make the other aspects of the solution more manageable.
>
> > ] Significant
> > ] reconfiguration of enterprise infrastructure and additional implementation
> > ] and support costs may be avoidable if a layered approach can be used to
> > ] meet security, filtering and support requirements.  Furthermore, it is not
> > ] clear how allocating new port numbers is consistent with the desire for
> > ] limiting use of new port numbers as has been seen in the case of SSL.
>
> The SSL problem has only a tiny bit to do with port exhaustion and more
> to do with "downgrading" - the practice of (for some protocols) trying
> SSL first, and if that fails, trying the non-SSL port.  and the problem is
> that this is easy to attack and provides a false sense of security.
> (admittedly, in-band negotiation of SSL only raises the bar a little bit)
> in general, opportunistic encryption is very hard to do, but that doesn't
> prevent people from trying naive approaches to it.
>
> > ] While we do not support the specification of bindings to HTTP for the
> > ] purpose of circumventing firewall policies, if a protocol uses the
> > ] documented application semantics and extensibility features of HTTP 1.1,
> > ] it should not be discouraged from using port 80.
>
> I have to disagree with the last statement - for reasons recently stated,
> there are often good reasons to discourage dissimilar services from all
> using port 80.
>
> > Also, I for one would be interested in your response to our comments, if
> > you could find them.  I don't know if the TAG would or not.
>
> I'll see if I can dig them up.
>
> Keith
>
>

Received on Monday, 8 April 2002 17:14:04 UTC