I recently encountered a certain security appliance (BlueCoat) which requires that all connections to the internet must be proxied through it (hello there, man-in-the-middle) and accordingly uses a special SSL certificate to intercept all traffic.
This prevented the normal operation of Git, even though the appropriate
http.sslCAInfo properties were set to make sure that the SSL connection itself works.
Using the environment variable
GIT_CURL_VERBOSE=1, we found that when using
git clone, a HTTP 407 (Proxy authentication required) occurs Git fulfils properly.
At the end of this, the appliance returns a HTTP 200 with a cookie header
Git then will connect to the target server, but without the cookie, leading to a HTTP 401.
The solution for this is to set the git configuration option
Is it actually permitted by the RFC standards that an intermediate proxy adds cookies?
Anthony Rich asked the same question to the http-state mailing list but without any response. He did note that in
RFC 2965 HTTP State Management Mechanism, 3.5 Caching Proxy Role it says:
Proxies MUST NOT introduce Set-Cookie2 (Cookie) headers of their own
in proxy responses (requests).
However, the superseding RFC 6265 doesn’t mention this anymore at all.
HTTP cookies are a hot mess. There is no real standard; the RFC, for what it’s worth, merely attempts to document what actual user agents are doing.
In any case, the RFC you probably want to read is RFC 7235, which specifies that proxies are supposed to send a Proxy-Authenticate header with the 401 error to request authentication information, and user agents receiving this are supposed to retry the request with a Proxy-Authorization header containing the authentication information for the proxy.
A number of challenge/response methods could be used to supply this information; the most widely used being “basic” (RFC 7617) as pretty much everything that speaks HTTP implements it.
Whether it’s allowed for a proxy to add or change cookies, I can’t say. The RFCs really don’t seem to be very clear on this point. It’s certainly unexpected behavior, especially for authentication. And BlueCoat has a long history of being mediocre in quality…
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.