1415488 - privacy.resistFingerprinting : USER-AGENT leaks when using the the HTTP CONNECT method

Status: RESOLVED DUPLICATE of bug 1419771

(Core :: DOM: Security, defect, P1)

Description

[theDeadDuck]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20100101

Steps to reproduce:

I set privacy.resistFingerprinting to TRUE
connect to mozilla.org:443 via http-proxy


Actual results:

The USER-AGENT leaks when using the the HTTP CONNECT method

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


Expected results:

The USER-AGENT must be the same as the one set by "privacy.resistFingerprinting"

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0

Comment 1

[Shian-Yow Wu [:swu]]

This should be DOM:Security. Ni? Ethan to confirm.

Comment 2

[Ethan Tseng [:ethan]]

(In reply to theDeadDuck from comment #0)
> Actual results:
> The USER-AGENT leaks when using the the HTTP CONNECT method

We can reproduce this bug.  Thanks for reporting it.

Comment 3

[Gary Chen [:xeonchen]]

In |nsHttpConnection::MakeConnectString| it tries to maintain a agent string [1], then it checks |ShouldResistFingerprinting|.
But [2] got a nullptr because [3] is null in socket thread, looks like it's supposed to be used only in DOM Worker thread?

[1] https://dxr.mozilla.org/mozilla-central/rev/2535bad09d720e71a982f3f70dd6925f66ab8ec7/netwerk/protocol/http/nsHttpConnection.cpp#2042
[2] https://searchfox.org/mozilla-central/rev/c99d035f00dd894feff38e4ad28a73fb679c63a6/dom/base/nsContentUtils.cpp#2458
[3] https://searchfox.org/mozilla-central/rev/c99d035f00dd894feff38e4ad28a73fb679c63a6/dom/workers/RuntimeService.cpp#1409

Comment 4

[Tim Huang[:timhuang]]

The nsContentUtils::ShouldResistFingerprinting() only works for the main thread and worker threads. So, for fixing this, I think there are two tracks:
  1. Making the nsContentUtils::ShouldResistFingerprinting() can check whether it is the socket thread; changing the check [1] into a check for both main thread and socket thread.
  2. Make Necko using nsRFPService::IsResistFingerprintingEnabled() directly when checking fingerprinting resistance.

Personally, I would prefer the first one since every other place for checking fingerprinting resistance is using this function in Gecko. However, I don't know is it desirable for Gecko to call OnSocketThread() since this function is only called inside Necko right now. But, actually, nsContentUtils can include `nsSocketTransportService2.h` and call OnSocketThread().

Gary, what do you think regarding this? 


[1] http://searchfox.org/mozilla-central/rev/c99d035f00dd894feff38e4ad28a73fb679c63a6/dom/base/nsContentUtils.cpp#2454

Comment 5

[Gary Chen [:xeonchen]]

(In reply to Tim Huang[:timhuang] from comment #4)
> The nsContentUtils::ShouldResistFingerprinting() only works for the main
> thread and worker threads. So, for fixing this, I think there are two tracks:
>   1. Making the nsContentUtils::ShouldResistFingerprinting() can check
> whether it is the socket thread; changing the check [1] into a check for
> both main thread and socket thread.
>   2. Make Necko using nsRFPService::IsResistFingerprintingEnabled() directly
> when checking fingerprinting resistance.
> 
> Personally, I would prefer the first one since every other place for
> checking fingerprinting resistance is using this function in Gecko. However,
> I don't know is it desirable for Gecko to call OnSocketThread() since this
> function is only called inside Necko right now. But, actually,
> nsContentUtils can include `nsSocketTransportService2.h` and call
> OnSocketThread().
> 
> Gary, what do you think regarding this? 
> 
> 
> [1]
> http://searchfox.org/mozilla-central/rev/
> c99d035f00dd894feff38e4ad28a73fb679c63a6/dom/base/nsContentUtils.cpp#2454

SGTM, just go ahead :)

Comment 7

[Andrea Marchesini [:baku]]

> Gary, what do you think regarding this? 

What about adding 'privacy.resistFingerprinting' using Preferences::AddBoolVarCache() in nsContentUtils::Init() ?
Nothing else needs to be done. You can then remove sPrivacyResistFingerprinting from nsRFPService.

Comment 8

[Tim Huang[:timhuang]]

(In reply to Andrea Marchesini [:baku] from comment #7)
> > Gary, what do you think regarding this? 
> 
> What about adding 'privacy.resistFingerprinting' using
> Preferences::AddBoolVarCache() in nsContentUtils::Init() ?
> Nothing else needs to be done. You can then remove
> sPrivacyResistFingerprinting from nsRFPService.

Actually, it did use Preferences::AddBoolVarCache() in nsContentUtils::Init(), but it has been moved into nsRFPService.cpp in Bug 1330890 according to Ehsan's suggestion, see Bug 1330890 comment 11 for details.

Comment 9

[Andrea Marchesini [:baku]]

That comment is actually good. We should not have 2 boolean cache vars. I would:
1. initialize it on the main-thread the addBoolVarCache in the component you prefer.
2. expose it as we do in nsContentUtils without having a WorkerPrefs.

Comment 10

[Tim Huang[:timhuang]]

(In reply to Andrea Marchesini [:baku] from comment #9)
> That comment is actually good. We should not have 2 boolean cache vars. I
> would:
> 1. initialize it on the main-thread the addBoolVarCache in the component you
> prefer.
> 2. expose it as we do in nsContentUtils without having a WorkerPrefs.

I can understand the point 1 here. But, I don't really get the point 2. Are you saying that we don't really need the workerPrefs check in nsContentUtils::ShouldResistFingerprinting() because we are using workerPrivate->ResistFingerprintingEnabled() to check this in other worker's code? So, the nsContentUtils::ShouldResistFingerprinting() will only be used in the main thread and the socket thread. Please correct me if I am wrong, thanks.

Comment 11

[Andrea Marchesini [:baku]]

>If you use an Atomic<bool> to store the value of this pref, you can call ShouldResistFingerprinting() from any thread.
No needs to use WorkerPrefs.

Comment 12

[Gary Chen [:xeonchen]]

This will be potentially fixed by bug 1419771.

Comment 13

[Ethan Tseng [:ethan]]

(In reply to Gary Chen [:xeonchen] (needinfo plz) from comment #12)
> This will be potentially fixed by bug 1419771.

Gary, can you verify this bug was fixed already.
If so, we set this bug as resolved duplicate by bug 1419771.

Comment 14

[Gary Chen [:xeonchen]]

From my GNU/Linux desktop, I can see the user-agent have been set to:

  User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox 59.0\r\n.

Case closed.

Comment 15

[Ethan Tseng [:ethan]]

(In reply to Gary Chen [:xeonchen] (needinfo plz) from comment #14)
> Case closed.

Nice!  :)