Opened 2 years ago

Last modified 2 years ago

#21361 new defect

Enable browser APIs only allowed in secure contexts for NG HS

Reported by: legind Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: arthuredelstein, gk, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Next Generation Hidden Services provide vastly improved protection against brute-force attacks than even many TLS certificates. Currently, hidden services can only utilize browser APIs which require secure context https://www.w3.org/TR/secure-contexts/ if they are provided over HTTPS.

The CA/Browser forum has allowed for Extended Validation HTTPS certificates to be issued for .onion addresses https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/, but this both a) requires deanonymization of the HS to comply with the EV requirements, and b) is often prohibitively expensive.

Explicitly allowing browser APIs for onion addresses which are only allowed in secure contexts, even if they are not provided over HTTPS, would fix this. It's important to note that the APIs which are allowed only in secure contexts have this restriction often because they are releasing personally identifiable information about the end user (such as location), but this is not necessarily the case. This obviously does not supersede the scrutiny individually applied to the various APIs wrt their privacy implications, which is quite a separate consideration.

Child Tickets

Change History (4)

comment:1 Changed 2 years ago by tom

I agree with this in theory (even for non NGHS) - but what APIs are you specifically interested in? I'm not sure if FF currently ships any such APIs that Tor Browser enables. For example: Web Bluetooth and EME we turn off; Service Workers is disabled in ESR also I believe. Is there any other such API? (In FF geolocation is not (yet?) required to be on a secure origin but of course we disable it.)

Last edited 2 years ago by tom (previous) (diff)

comment:2 Changed 2 years ago by legind

I think the Push API might be a powerful feature once we migrate to Firefox 52 ESR in March. From my testing, it isn't yet fully implemented in 45 ESR. We'd have to consider the security and privacy considerations https://www.w3.org/TR/push-api/#security-and-privacy-considerations and whether this aligns with the Tor Browser design principle of Disk Avoidance. https://www.torproject.org/projects/torbrowser/design/#disk-avoidance

comment:3 Changed 2 years ago by legind

Likely there will be further APIs that move towards secure context as well. In Chrome, for instance, the MIDI permission context is restricted to secure origins as well:

https://cs.chromium.org/chromium/src/chrome/browser/media/midi_permission_context.cc?q=IsRestrictedToSecureOrigins+package:%5Echromium$&dr=CSs&l=40

comment:4 in reply to:  2 Changed 2 years ago by gk

Replying to legind:

I think the Push API might be a powerful feature once we migrate to Firefox 52 ESR in March. From my testing, it isn't yet fully implemented in 45 ESR. We'd have to consider the security and privacy considerations https://www.w3.org/TR/push-api/#security-and-privacy-considerations and whether this aligns with the Tor Browser design principle of Disk Avoidance. https://www.torproject.org/projects/torbrowser/design/#disk-avoidance

I think Push (as Service Workers) won't be available in ESR52: See: https://groups.google.com/forum/?_escaped_fragment_=topic/mozilla.dev.platform/TWE4VEbJOmM#!topic/mozilla.dev.platform/TWE4VEbJOmM

Note: See TracTickets for help on using tickets.