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
