Re: [squid-users] Bugs in IE digest proxy auth

On Fri, 27 May 2005, Joshua Goodall wrote:

> I've observed three bugs in IE6's digest proxy authentication implemention.
> Is anyone able to confirm that it's Not Just Me, and whether any good
> workarounds are already out there?

IS6 is well known for being broken in it's authentication support in
variuous manners (details varies greatly with the patch level or hotfixes
used)

> 1. Double-quote-marks in URLs. IE sends a digest-uri-value that's improperly
> escaped, as in (when visiting http://localhost/test.html"foo):

What can I say?

URL-escaping seems to be a very hard thing to do for some unknown reason..
most clients gets URL-escaping wrong one way or another when given bad
URLs as input..

Yes, the above URL is an invalid URL as the " MUST be escaped according to
the URL standard (RFC 1738) where " is in the set of unsafe characters
which must always be encoded (RFC1738 section 2.2, subsection "Unsafe"),
which means that whoever typed/generated such URL as input to the client
placed himself outside standards.. Clients (and servers) are not required
to accept bad URLs, but at th same time they MUST NOT send bad URLs.

> Digest username="User Name", realm="Login", qop="auth", algorithm="MD5", uri="/test.html"foo", nonce="q3...
> vs Firefox which sends:
> Digest username="User Name", realm="Login", nonce="42yWQuDPGw/gebJ8", uri="/test.html%22foo", response="666...

Another interesting point is that neither is correct for proxy
authentication. The uri should be identical to the request-URI which for
proxy requests is an absoluteURI http://www.example.com/test.html%22foo

Related question: What was the request-URI on the request line send by IE
in the above? Was this escaped properly or where it using unescaped quote
there as well?

> 2. Never reuses a nonce - always sends a request, gets a 407 challenge
> with a new nonce value, then reissues the request with the correct
> Proxy-Authorization header; this doubles the number of actual HTTP
> requests; is there a workaround?

Uncertain. nonce reuse is quite dependent on the client having support for
this. It may obviously be the case that IE do have support for nonce reuse
but for some reason refuses to do so with Squid but it's very hard to know
outside Microsoft.

The only thing I can think of is to make sure there is persistent
connections enabled. I could imagine that nonce reuse may be related to
connection reuse in some clients.

> 3. IE gets confused when a website uses a 401 authentication challenge.
> In this case, it prompts for and sends the Authorization: header,
> but then repeatedly re-prompts the user for their proxy credentials.

Nice...

> I've worked around this by inventing the following access list:
>
> acl msie-win-browser browser MSIE.*Windows
> acl basic-auth auth_regex Basic
> auth_param digest access deny msie-win-browser basic-auth
> auth_param digest access allow all
>
> Yes, I had to invent "auth_regex" and "auth_param digest access".
> This ACL effectively downgrades the user to using basic proxy auth
> if using basic www auth.

Interesting. So this worked around the problem for you?

> I'd especially like a solution for bug 3, because the workaround is
> ugly, insecure and expensive. I have a case open with Microsoft Partner
> Support right now.

Probably the only viable path to find a good solution to this problem.

> Oddly enough, IE5 on the Mac doesn't have any of these symptoms.

More proof of the above.

On a related note I have the impression that the HTTP support in MSIE has
degraded noticeably with the MSIE6 release, and that it has since then
been a big patchwork to get things running.. especially in areas relating
to authentication where I do not know a single MSIE6 version which gets it
correct.. (always one scheme broken)

There is also issues in connection management when accessing secure sites
(accidental reuse of existing connection without enabling SSL, sending the
supposedly protected request in plaintext...), and a handful of other
issues I do not remember right now.

Regards
Henrik
Received on Fri May 27 2005 - 02:27:53 MDT