1816115 - Netmonitor shows http header "proxy-authentication" that isn't actually sent to the receiving server

Status: RESOLVED FIXED

(DevTools :: Netmonitor, defect, P3)

Description

[davidz.bb]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

In Network settings, add a http proxy with username and password.

Actual results:

In the proxy, for the request of CONNECT method, it sends 407 to firefox to challenge basic authenticate, then firefox sends http header proxy-authentication to proxy, after it is validated successfully, the proxy connects the 2 sockets (the one to firefox and the one to the target host) as a channel. The problem is that for the following http requests via this channel, firefox still sends http header proxy-authentication, which exposes the secret username/password to the remote host.

Expected results:

The following http requests via the channel created by CONNECT should not send http header proxy-authentication for security, just like what Safari or Chrome does.

Comment 1

[Daniel Veditz [:dveditz]]

It's not clear this is wrong. Traditionally proxy auth worked like regularly http auth: you had to send the header with each request or the proxy would send you another 407 (HTTP is famously a "stateless protocol"). If you didn't send the header the first time then every request had to be made twice as you replied to all the 407s. The HTTP spec (rfc9110) says the proxy that requested the auth is supposed to "consume" the header and not send it along.

But maybe more modern versions of HTTP (e.g. HTTP/2 or /3) no longer require that?

Comment 2

[davidz.bb]

I agree that browser should send proxy authentication header the first time for CONNECT if it is challenged by code 407.

Section 9.3.6 of rfc9110 says "Proxy authentication might be used to establish the authority to create a tunnel". My understanding is that Proxy authentication is used in CONNECT to create the tunnel. Once the tunnel is established, all the following requests via the tunnel are directly sent to the target host, which should not bring proxy authentication header. e.g. It is valid that browser sends https requests to target host (SSL handshake is between browser and target host) via the tunnel established by a http proxy. In this case, the proxy have not way to listen the https payloads so it cannot stripe proxy authentication header from the requests. Thus proxy authentication will be sent to the target host unexpectedly.

Comment 3

[davidz.bb]

Actually I mean Proxy-Authorization instead of proxy authentication.

CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
Proxy-Authorization: basic aGVsbG86d29ybGQ=

Comment 4

[Valentin Gosu [:valentin] (he/him)]

I think the reporter's assessment is correct.
We shouldn't set a Proxy-Authorization header on HTTP(S) requests going through a HTTPS tunnel, or HTTPS requests going through an HTTP tunnel - even for HTTP/1.1. HTTP requests through an HTTP proxy should keep sending the Proxy-Authorization, because the proxy is possibly stateless. Given H2 and H3 are always encrypted, I think we shouldn't send the Proxy-Authorization for any non-CONNECT requests going to a H2 or H3 proxy.

Comment 5

[Kershaw Chang [:kershaw]]

Hi Reporter,

Could you share how did you observe this issue?
According to the code here, Firefox does prune Proxy-Authorization for the requests that will go through a tunnel.

Thanks.

Comment 6

[davidz.bb]

1. In network settings, add a http proxy with username/password.
2. Browse a website via the http proxy.
3. Right-click on the web page, and choose Inspect.
4. Click Network on the tab, choose any GET or POST request on the left side, then check the headers on the right side, you will see Proxy-Authorization Basic XXXXX in the request headers.

Comment 7

[Valentin Gosu [:valentin] (he/him)]

If I use mitmproxy --proxyauth="user:pass" then navigate to http://httpbin.org/headers I don't see the proxy-authorization being reflected back.

Comment 8

[Kershaw Chang [:kershaw]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #7)

If I use mitmproxy --proxyauth="user:pass" then navigate to http://httpbin.org/headers I don't see the proxy-authorization being reflected back.

Right, I think we don't send Proxy-Authorization to the server when CONNECT is used.
I think this is a devtool issue.

I'll let devtool people decide whether to show Proxy-Authorization.

Comment 9

[davidz.bb]

I am using this simple proxy written in GoLang,

package main

import (
"github.com/elazarl/goproxy"
"log"
"net/http"
"flag"
)

var portNumber = flag.String("port", "12345", "port number")

func main() {
proxy := goproxy.NewProxyHttpServer()
proxy.Verbose = false

log.Println("auth basic")

log.Println("listen:" + *portNumber)
log.Fatal(http.ListenAndServe(":" + *portNumber, proxy))

}

Comment 10

[davidz.bb]

It is surprising that the headers are different between http://httpbin.org/headers and devtool's request headers:

{
"headers": {
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8",
"Accept-Encoding": "gzip",
"Accept-Language": "en-US,en;q=0.5",
"Host": "httpbin.org",
"Upgrade-Insecure-Requests": "1",
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0",
"X-Amzn-Trace-Id": "Root=1-63eb93af-44c768f60442df520250513e"
}
}

=================================

GET /headers HTTP/1.1
Host: httpbin.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Authorization: Basic XXXXXXXXXXX
Connection: keep-alive
Upgrade-Insecure-Requests: 1

Comment 11

[Valentin Gosu [:valentin] (he/him)]

That's because the Proxy-Authorization header is set on the channel, but isn't actually sent to the server.
This line here strips the proxy headers before sending them out the the server.

Comment 12

[:Gijs (he/him)]

Valentin, am I right in thinking we can remove the security flag here?

Comment 13

[Valentin Gosu [:valentin] (he/him)]

Yes, I think we can remove the security flag.

Comment 14

[Hubert Boma Manilla (:bomsy)]

If the Proxy-Authorization is not sent to the server (for non CONNECT), we could

• Strip it out and not show it in devtools or
• Show it but some sort of visual indicator (grayed out) in devtools indicating that the request header is not actually sent.

Any thoughts?

(In reply to Valentin Gosu [:valentin] (he/him) from comment #7)

If I use mitmproxy --proxyauth="user:pass" then navigate to http://httpbin.org/headers I don't see the proxy-authorization being reflected back.

When i switched to the headers tab on http://httpbin.org/headers i can see the Proxy-Authorization on the list of request headers, but its not part of the JSON or Raw Data. I guess there is slight difference??

I noticed the Proxy-Authorization is also shown in the chrome devtools?

Comment 15

[Hubert Boma Manilla (:bomsy)]

Attachment: Bug 1816115 - [devtools] Stop showing the Proxy-Authorization header r=#devtools-reviewers

Comment 16

[Valentin Gosu [:valentin] (he/him)]

I think not showing it in devtools is the right choice - the header is not being sent to the server
We can also probably improve the proxy visibility story with bug 1707192 and related bugs.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6ebd1e29a72e
[devtools] Stop showing the Proxy-Authorization header r=devtools-reviewers,nchevobbe

Comment 18

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/6ebd1e29a72e