At 03:57 AM 7/19/2005, Roy T. Fielding wrote: >On Jul 18, 2005, at 12:30 PM, William A. Rowe, Jr. wrote: >>> NTLM HTTP Authentication >>> (and possibly other connection-oriented >>> HTTP authentication and authorization protocols) >>> is insecure by design > >Yep, no shit -- that's what the Microsoft fools were told when >they introduced it.
That doesn't surprise me :) >>>*) The web server (IIS/6.0) must receive a Via-less request. The >>>Microsoft implementation assumes that the Via header is always sent >>>by a proxy server, and this is indeed mandated by the HTTP/1.1 RFC >>>2616 (http://www.ietf.org/rfc/rfc2616.txt), section 14.45: >>> The Via general-header field MUST be used by gateways and proxies >>> to indicate the intermediate protocols and recipients between the >>> user agent and the server on requests [...] > >Yep. > >>>However, it seems that not all servers adhere to this standard. For >>>example, Apache 2.0.54 mod_proxy does not generate a Via header by >>>default (see the ProxyVia directive - >>>http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxyvia, yet >>>the default httpd.conf file contains a commented-out "ProxyVia On" >>>directive, so it's possible that many Apache proxy deployments do > >WTF? That's a bug. I'd say. The question is; what's the fix? Today's syntax is ProxyVia on|off|full|block The default is off, which is clearly invalid. A default of full might be overkill, default of on should be sufficient Are ProxyVia off and ProxyVia block invalid? Technically, it's pretty clear that they are. Realistically, if someone wants an invisible proxy, I guess that's up to them, but then again it's their own damned fault if they trip over something like this. But we don't give them much choice today, I don't think... The 14.45 Via section defines a pretty clear acceptable flavor, [...] The received-by field is normally the host and optional port number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to be sensitive information, it MAY be replaced by a pseudonym. If the port is not given, it MAY be assumed to be the default port of the received-protocol. Sooo... a new alternative, "ProxyVia alias shortname" would seem sane, and a much better choice for most reverse proxies. For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. For example, Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy could be collapsed to Via: 1.0 ricky, 1.1 mertz, 1.0 lucy Applications SHOULD NOT combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced by pseudonyms. Applications MUST NOT combine entries which have different received-protocol values. Sooo... "ProxyVia collapse shortname" would be an even terser flavor, and I can't see a case where we would keep the truename of this via server while collapsing the rest. Thoughts? Bill
