1017769 - HTTPS proxy CONNECT leaks Host header of tunneled request

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[David Fifield]

Attachment: Demo extension: unzip in extensions directory and watch requests to the HTTP proxy on startup.

1. Start an HTTPS proxy with logging of requests (for example, "ncat -l --proxy-type http -vvv").
2. Configure Firefox to use an HTTPS proxy (localhost:3128 if using the ncat command).
3. Extract the attached [e-mail] extension to the extensions directory. The extension opens an nsIHttpChannel to "https://www.google.com/test" but sets the Host header to "cors-test.appspot.com".
4. Run Firefox and watch the requests to the proxy. (The extension is a browser overlay, so you can get it to run again by opening a new window.)

The proxy CONNECT request has www.google.com in the Request-Line but cors-test.appspot.com in the Host header:

CONNECT www.google.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: cors-test.appspot.com

What would be better for me is if the Host header also said www.google.com. The attached patch does it:

CONNECT www.google.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: www.google.com:443

Since bug 82388, nsHttpConnection::MakeConnectString peeks into the plaintext of the tunneled request, in order to copy the Host header into the proxy CONNECT request (https://hg.mozilla.org/mozilla-central/file/1e712b724d17/netwerk/protocol/http/nsHttpConnection.cpp#l1762). The Request-URI host:port string, on the other hand, is constructed out of the destination info. The Host header in the proxy request is only there because HTTP/1.1 requires it (see discussion on bug 82388). In most cases these two strings will be the same; but when they are not, it's better to avoid revealing parts of the tunneled request.

Note that changing the Host header on the proxy request doesn't affect the Host header in the tunneled request. The tunneled host header is unchanged and is interpreted by the remote server. In this example, you can set browser.dom.window.dump_enabled and see that the result of the request is the expected '{"status":"ok"}' from https://cors-test.appspot.com/test, and not the 404 from https://www.google.com/test.

Why would anyone want to do this weird thing? Send a request with a Host header different from the authority in the URL? We are investigating it as a technique for circumventing Internet censorship--it appears to a censor that you are contacting one domain, when you are actually contacting another. (In this case, www.google.com internally dispatches the request to an appspot.com server.) We're using a Firefox extension as an HTTPS camouflage layer, and it works well. It would be even better to use the same system through an upstream HTTP proxy, without revealing the covert destination. https://trac.torproject.org/projects/tor/ticket/12146 is this issue on Tor's bug tracker.

Comment 1

[David Fifield]

Attachment: MakeConnectString-host.patch

Patch to make nsHttpConnection::MakeConnectString use the same string for Host as it uses for Request-URI.

Comment 2

[Patrick McManus [:mcmanus]]

I'll take the patch with a green try run.

Comment 3

[David Fifield]

How do I do that? I don't have a commit account.(In reply to Patrick McManus [:mcmanus] from comment #2)
> I'll take the patch with a green try run.

How do I do that? I don't have a commit account.

Comment 4

[Georg Koppen]

(In reply to david from comment #3)
> How do I do that? I don't have a commit account.(In reply to Patrick McManus
> [:mcmanus] from comment #2)
> > I'll take the patch with a green try run.
> 
> How do I do that? I don't have a commit account.

I take care of it.

Comment 5

[Georg Koppen]

(In reply to Patrick McManus [:mcmanus] from comment #2)
> I'll take the patch with a green try run.

Try is green: https://tbpl.mozilla.org/?tree=Try&rev=6350cf56b7b4

Comment 6

[Patrick McManus [:mcmanus]]

actually - can you run all the tests (on just one platform) - the CI uses a lot of proxy connects

Comment 7

[Georg Koppen]

green as well: https://tbpl.mozilla.org/?tree=Try&rev=6c98dca0c285

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a1f6458800d4

Should this have a test or is it covered by existing ones?

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a1f6458800d4