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:
- If the SOCKS username eTLD matches the destination eTLD, resolve via Prop279 like we do now.
- 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.
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:
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.onioneTLD will not have any security degradation from this, because Tor will see it as an invalid.oniondomain, and not leak it to an exit relay. It should also be noted that.bitdomains 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..bitdomains 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.bitdomains 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.bitdomains, even when onion services are used (or else make it clear that.bitdomains that resolve via non-TLS onion services should not be used as subresources of first-party non-.bitdomains).This behavior should be optional. Some users may prefer to never leak resolution to an exit relay, even if it makes fingerprinting easier.