cURL / Mailing Lists / curl-library / Single Mail


proxy authentication bugs (was: Problem with NEGOTIATE-Proxy-Authentication and not reusing underlying TCP-Connections)

From: Stefan Bühler <>
Date: Mon, 3 Nov 2014 13:38:09 +0000


as a follow up to our problem with Negotiate Proxy-Authentication I'd
like to post the following list of bugs we ran across:

* "Proxy-Authentication: Negotiate" headers are never removed;
  Negotiate authenticates the connection and some proxies break if
  they receive it unexpectedly (MS Proxy with POST requests).
* "Proxy-Authentication:" headers are not removed when the connection
  is reused in a different easy handle. The new easy handle won't know
  which authentication method was picked and won't cleanup or generate
  new headers.
* Not reusing easy handles (curl_easy_reset) basically breaks anything
  related to (proxy) authentication.

  When I said curl_easy_reset and curl_easy_cleanup + curl_easy_init
  (while using multi handle) should behave the same I didn't mean you
  should break curl_easy_reset :) You should fix cleanup + init by
  putting more state into the multi-handle; or at least add a note to
  the docs recommending to reuse the easy handles. (Because to me it
  sounded like curl_easy_reset was just saving some frees and allocs
  when used with multi handle, and this is certainly not the case).

  From a security point of view you are screwed anyway with multi
  handle; if you reuse a connection which was authenticated (NTLM or
  Negotiate) in a new handle you inherit the credentials, whether you
  passed them again or not. (And right now you also inherit the Basic
  and Digest proxy authentication headers; Basic will continue to
  work, and Digest often works more than once.)

  As we are reusing easy handles now I don't care much what happens
  about this; I just wanted to summarize it again.

* Connections are reset while doing "Negotiate" authentication if
  the request has a body. (lib/http.c:425)
  The proxy will deny the authentication in a new connection; similar
  to NTLM it has to be ensured that the authentication happens in the
  same connection.
* While doing Proxy-Authentication for CONNECT requests curl sometimes
  thinks it has data to send (POST to https) and resets the
  connection, although there is no need.
  (wrong expectsend in lib/http.c:400)
* curl does an unneeded additional round-trip for authentication:
  in the first round it iterates over the available authentication
  headers, then picks one - but doesn't actually handle the header.
  It then sends a new request before actually handling the header;
  instead it should iterate over the headers from the first request

I extended my patch for headers (point 1) to also fix point 4 and 5
in the list above, and I'd like to get some feedback; especially
whether this:

        bool proxy_connect_auth = (0 == http->writebytecount) && (!conn->bits.protoconnstart);

is a correct way to detect whether we are currently proxy-
authenticating a CONNECT (and don't have any bytes to send as "body").
(The writebytecount check is only a "safety" check - if there are no
bytes to send no bytes should have been sent.)


List admin:

Received on 2014-11-03