Currently, StemNS exits when the control port is disconnected. This is fine for Tor Launcher contexts, but is not desirable for service contexts such as Whonix, Tails, and winsvcwrap. It looks like onion-grater already has control connection management code that is reasonably battle-hardened; we should probably just copy that code.

We should add an option (per eTLD) to reject destinations that are not .onion domains if they are using TCP port 80. This has the effect of guaranteeing that the eTLD will use a secure origin for HTTP traffic.

The executable name poc.py is awful. It's legacy inherited from TorNS, and never should have entered production. I suspect that packagers will want it renamed. Perhaps stemns.py? Not sure what Debian's policies on capitalization are.

Spawned name services were breaking on Windows without 9d2a5c5 . We should figure out why upstream TorNS didn't pass-through env... was it intended to be a security feature?

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.

When StemNS is active, Tor sometimes hangs during bootstrap (typically at Bootstrapped 40% (loading_keys): Loading authority key certs). This appears to be because StemNS tries to attach streams whose purpose is DIR_FETCH. Such streams are automatically attached by Tor even if __LeaveStreamsUnattached is set, which produces a race condition where the stream is attached twice.

Seems we can have several categories of config: etld.conf.d, bootstrap.conf.d, and exit.conf.d. This would make packaging cleaner, as per advice from the Whonix devs.

Tor supports an auto port number; we should support this.

StemNS should shut itself down, along with any plugins, when Tor shuts down. This is a prerequisite to https://gitlab.torproject.org/tpo/applications/tor-launcher/-/issues/40001 .

I have tried to resolve a .pet.onion using StemNS. I have followed the instruction in poc.py.

# virtualenv venv
# source venv/bin/activate
# pip install --upgrade pip
# pip install stem
#
# Then you can run this:
# python3 poc.py

It has installed for me stem == 1.8.0 and it seems to fail silently when trying to compare the stream status

        if stream.status != stem.StreamStatus.CONTROLLER_WAIT:

Looking at the stem library I don't see a CONTROLLER_WAIT status? see documentation https://stem.torproject.org/api/control.html#stem.StreamStatus