search

namecoin / StemNS

Implement Proposition 279 (Pluggable Naming) w/o changing Tor (Stem port)
https://www.namecoin.org/
The Unlicense
7 stars 9 forks source link

Optionally resist fingerprinting #15

Open JeremyRand opened 4 years ago

JeremyRand commented 4 years ago

Tor Browser instances that use StemNS are vulnerable to fingerprinting, because a website can probe for StemNS-based eTLD's via subresource loading. This is arguably not a huge deal, since each supported naming system only adds 1 bit of fingerprintability. It is also arguably not a huge deal because we intend to make Namecoin support the default. However, IMO it's still a problem that we should fix, especially during the transitional period where Namecoin support isn't ubiquitous.

Tor Browser exposes the first-party eTLD+1 via the SOCKS username. We can thus resist fingerprinting like this:

  1. If the SOCKS username eTLD matches the destination eTLD, resolve via Prop279 like we do now.
  2. If the SOCKS username eTLD does not match the destination eTLD, leak the resolution to the exit relay (as though StemNS were not active).

This will prevent websites from fingerprinting StemNS-based eTLD's via subresource loading. It will not prevent websites from fingerprinting StemNS-based eTLD's via first-party redirects, but that's outside of Tor Browser's threat model anyway. It will cause some security degradation, in that websites with a DNS-based first-party domain who access subresources on Namecoin will be vulnerable to hijacking of those subresources by malicious exit relays.

Note that we do not simply return a resolution error in case 2, because that would be fingerprintable based on the delay taken for an error to happen while loading the subresource.

It should be noted that the .bit.onion eTLD will not have any security degradation from this, because Tor will see it as an invalid .onion domain, and not leak it to an exit relay. It should also be noted that .bit domains with TLS enabled will not be hijackable unless the exit relay is colluding with a compromised TLS CA, and ncp11 is not installed in Tor Browser. .bit domains that resolve via an IP address without TLS are vulnerable to hijacking either way, so that's not really a problem. The major source of security degradation is .bit domains that resolve via an onion service without TLS. I tend to think that the "right" way to handle this is to encourage usage of TLS with .bit domains, even when onion services are used (or else make it clear that .bit domains that resolve via non-TLS onion services should not be used as subresources of first-party non-.bit domains).

This behavior should be optional. Some users may prefer to never leak resolution to an exit relay, even if it makes fingerprinting easier.

yanmaani commented 2 years ago

I think it seems gross to leak it to the exit relay; I'd rather we first try and get a patch done in upstream that makes it so that it will never try to resolve .bit domains by default, as if it were a suTLD. (The further upstream we can get this, the better it would be for the goals of the project.)

JeremyRand commented 2 years ago

I think it seems gross to leak it to the exit relay; I'd rather we first try and get a patch done in upstream that makes it so that it will never try to resolve .bit domains by default, as if it were a suTLD. (The further upstream we can get this, the better it would be for the goals of the project.)

@yanmaani I think this is orthogonal. If I were implementing such a patch upstream, I would make Tor automatically close any streams for .bit domains as soon as they are attached to a circuit. And the way StemNS would resist fingerprinting would be by attaching .bit streams that pose a fingerprinting hazard to a circuit. So, the behavior by StemNS would be unchanged regardless of whether Tor has such a patch.