httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: NTLM HTTP Authentication is insecure by design - a new writeup by Amit Klein
Date Wed, 20 Jul 2005 06:43:34 GMT
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






Mime
View raw message