On Fri, 1 Aug 2003, Serge Semashko wrote:

> Here is the update to NTLM proxy patch, it adds CURLOPT_PROXYAUTH option
> similar to CURLOPT_HTTPAUTH.

Nice work!

> It is not complete but I hope it does not break anything. The old code for
> proxy basic authentication is still used when only CURLAUTH_BASIC flag is
> set in CURLOPT_PROXYAUTH option (it is the default value). Only NTLM
> authentication for proxies is supported with the new code (digest, basic,
> and the others are still to add).

That'll be OK. When I know it works good for an NTLM proxy, I'll setup a
couple of test cases that'll test 1) NTLM proxy functionality and 2) proxies
support NTLM *or* Basic and then we can work out all the little quirks that
might be left.

The only major thing I missed in your patch is what you did to the client-side
code to actually use this code with curl! ;-)

> I successfully managed to access digest authenticated web server through
> NTLM proxy with this patch. But it still probably needs more testing with
> different proxy/web authentication configurations and your review just to be
> sure it does not break anything.

I found one issue by running the test suite. I'd recommend you to try running
it! ;-)

In case you can't run it for some reason, I'll describe the problem (called
bug B) shortly here:

The test case uses a HTTP proxy and requests a HTTPS page through it, both
with Basic authentication (using the same name and passwords for both just to
make it easier).

The first thing that struck me, is that we have a rather serious
authentication info reveal bug here that you're not the source of (called bug
A here). The mistake is all mine and its pretty stupid how its lying all here
(spelled out in the clear in the test case) without me having actually seen it
before.

OK, the full request from a perfectly working (with bug A fixed) curl should
look like this (indented for increased readability):

  CONNECT 127.0.0.1:8433 HTTP/1.0
  Proxy-authorization: Basic dGVzdDppbmc=

  GET /503 HTTP/1.1
  Authorization: Basic dGVzdDppbmc=
  Host: 127.0.0.1:8433
  Pragma: no-cache
  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Before your patch, bug A causes the request to look like this:

  CONNECT 127.0.0.1:8433 HTTP/1.0
  Proxy-authorization: Basic dGVzdDppbmc=

  GET /503 HTTP/1.1
  Proxy-authorization: Basic dGVzdDppbmc=
  Authorization: Basic dGVzdDppbmc=
  Host: 127.0.0.1:8433
  Pragma: no-cache
  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Bug A causes curl to *leak* proxy auth information to the target server! It
wrongly includes the authentication header in the request that it tunnels
through the proxy. Bad bad curl.

Anyway, with your patch applied, all we get left of the authorization in the
tunneled request is the faulty one. The proper host-auth header has now fallen
off (bug B):

  CONNECT 127.0.0.1:8433 HTTP/1.0
  Proxy-authorization: Basic dGVzdDppbmc=

  GET /503 HTTP/1.1
  Proxy-authorization: Basic dGVzdDppbmc=
  Host: 127.0.0.1:8433
  Pragma: no-cache
  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

I suspect this happens because you're assuming that there won't be a
host-request after we've done a proxy-request on the same connection, but for
tunneled requests and HTTPS-over-proxy, this is the case.

If you fix bug B, I'll apply your patch. You can leave bug A for me to fix, I
think I have a pretty good idea how to handle it.

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01