Closed Bug 1415488 Opened 3 years ago Closed 3 years ago

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

Categories

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

50 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1419771

People

(Reporter: zope, Assigned: xeonchen)

References

Details

(Whiteboard: [fingerprinting][domsecurity-active])

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
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
This should be DOM:Security. Ni? Ethan to confirm.
Component: Networking: HTTP → DOM: Security
Flags: needinfo?(ettseng)
Flags: needinfo?(ettseng)
Priority: -- → P1
Whiteboard: [fingerprinting]
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
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
Flags: needinfo?(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 :)
Flags: needinfo?(xeonchen)
Duplicate of this bug: 1416273
> 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.
(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.
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.
(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.
Flags: needinfo?(amarchesini)
>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.
Flags: needinfo?(amarchesini)
Assignee: nobody → tihuang
Depends on: 1417741
Whiteboard: [fingerprinting] → [fingerprinting][domsecurity-active]
See Also: → 1419771
Assignee: tihuang → xeonchen
This will be potentially fixed by bug 1419771.
Depends on: 1419771
(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.
Flags: needinfo?(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.
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(xeonchen)
Resolution: --- → DUPLICATE
Duplicate of bug: 1419771
(In reply to Gary Chen [:xeonchen] (needinfo plz) from comment #14)
> Case closed.

Nice!  :)
You need to log in before you can comment on or make changes to this bug.