This thread is for technical discussion of how Namecoin might be integrated into Whonix. Conceptual / high level discussion (e.g. “Should Namecoin integration happen in Whonix?”) should go in Namecoin Integration in Whonix instead (see that thread for background info). (I’m splitting the discussion into 2 threads at Patrick’s request.)
A couple of starting points for discussion:
We’re working on getting the Tor-relevant Namecoin components packaged in Debian, but since Bullseye has (AFAIK) already reached its freeze date, I don’t think it’s possible for us to get Namecoin into Bullseye. Getting into Bullseye-Backports may be feasible though, depending on how the Debian folks feel about it (I’m not certain what their policies are on getting into Backports). However, it should be noted that most of the Tor-relevant Namecoin components are available as either an AppImage (e.g. Electrum-NMC) or a statically linked Go binary (e.g. ncprop279). (I think both the AppImage and the Go binaries build reproducibly, though the build reproducibility is not routinely audited yet .) I’m curious whether it would be feasible to get those components into
binaries-freedom, or if it would be strongly preferred to get packaged in Debian itself (which might incur some delay).
Namecoin uses StemNS (our fork of meejah’s TorNS, which adds some security features like stream isolation support) to intercept
STREAM events from the Tor control port, and perform resolution on them via the
REDIRECTSTREAM command. This raises some questions about what the best approach is to running this under Whonix. The
REDIRECTSTREAM command is somewhat dangerous if not contained. I’m not sure of the best way to contain it with onion-grater… perhaps there’s a way for onion-grater to block StemNS from redirecting any streams that don’t initially have a
.bit (Namecoin) domain as their destination. Care would also need to be taken to make sure that multiple Whonix-Workstation VM’s don’t interfere with each other. StemNS should, I think, be safe to run in its own Workstation VM, and handle all the Namecoin resolution for all other Workstation VM’s that are hooked up to that Gateway, but this may be unreasonable from a resource usage perspective (a lot of users may not want to run an extra Workstation VM just to use Namecoin). The core security considerations here are (1) we don’t want multiple StemNS instances to try to handle the same
STREAM event, and (2) if a StemNS instance is in a compromised Workstation VM, then that could compromise whatever streams in other Workstation VM’s are resolved by that compromised StemNS.
Probably plenty of other technical discussion points to be had, but I’ll start with those. Thoughts?
 I gave a presentation at a recent Tor Demo Day on using Cirrus CI as a reproducible build co-signer for Tor Browser’s RBM build system; this work should result in an improvement with respect to regular auditing of build reproducibility of anything that uses RBM, which includes Namecoin’s Go binaries.
This is mostly about resolving
.bit inside Whonix? Or and/or namecoin wallet?
.bit is installation of namecoind required? Would namecoind (or anything) need to download a ~ 300 GB blockchain? What are the disk space requirements? Or can
ncdns be used standalone?
A separate VM for namecoin only seems overkill indeed at this point.
Realistic to get namecoin integrated into Tor instead the browser (Tor Browser)?
How to start simpler…? Using namecoin on Debian? The web search results for that aren’t great.
I am asking because perhaps namecoin integration would be easier if done on Whonix-Gateway.
Would also be interesting to see how Tails integration would go. (Tails used to have monkeysphere and i2p integration. Wondering if that indicates openness for namecoin integration.)
Ideally this could be implemented as an add-on package. That would be cleaner. This is even unspecific to Whonix. Also for users of Debian it would be much better if they could “sudo apt install namecoin”.
(The request for being an add-on package is unrelated to Namecoin Integration in Whonix, opt-in vs default installation.)
ncdns requires modification of system DNS configuration file
/etc/resolv.conf as far as I understand. For sake of being an add-on package, for better usability, could you please support something like
/etc/resolv.conf.d? I think that requires package
resolvconf. Long ago since I looked into that. Avoided for lower complexity. Maybe now would be a time to reconsider that.
By supporting dropping a snippet into
/etc/resolv.conf.d things would look much better. In my very strong opinion, Debian (and similar for other Linux distribution) installation experience needs to boil down to a “sudo apt install namecoin” level of simplicity. An "oh but you need to edit
/etc/resolv.conf" would be a major usability issue.
Needing to edit a configuration file such as
/etc/resolv.conf is bad. Not exactly but Modifying Default Configuration of Third Party Packages is realted. I can make a stronger case for that if needed.
ncdns supports using Tor’s
ncdns isn’t needed / supposed for this use case then might question might not make sense / not be important.)
Lots of good questions here.
.bit inside Whonix is most interesting to me, and is the intended purpose of this thread. I would not be opposed to having a Namecoin wallet in Whonix, but it’s not why I started the thread.
Namecoin Core (the daemon version of which is called namecoind) is one option, but not the only option; Electrum-NMC is an option as well. The Tor Browser developers prefer Electrum-NMC due to its lower bandwidth requirements (as per your next question).
If Namecoin Core is used, it would need to download the Namecoin blockchain, which is ~4.6 GiB. Much smaller than the Bitcoin blockchain, but still significant. Electrum-NMC only downloads recent block headers (specifically, headers that are after the checkpoint). A chunk of 2016 headers typically uses ~3.5 MB of download bandwidth (we think this can be optimized down to ~1.4 MB if needed). We typically include a checkpoint when tagging a release that is circa 2 chunks behind the release date. So that’s about 7 MB of download bandwidth on the first run. A new chunk of ~3.5 MB accumulates approximately every 2 weeks, which users will need to download in order to stay synced. So, the bandwidth usage of Electrum-NMC is pretty low. My guess is that Whonix would prefer Electrum-NMC over Namecoin Core for this reason (but this is up to you).
Namecoin Core supports pruning. Most of the storage used by Namecoin Core when pruning is enabled is in the UTXO database (i.e. the
chainstate folder). That folder on my Namecoin Core node is currently 806.1 MiB.
The Electrum-NMC data folder in my regularly-used Tor Browser Nightly instance is 41.5 MiB (most of which is the blockchain headers file). However, I noticed that if I compress that folder via Dolphin’s default tar.gz settings, it compresses quite well down to 3.0 MiB, which suggests that the 41.5 MiB figure could maybe be significantly reduced if you consider it too high.
(Again, up to you whether you prefer Namecoin Core or Electrum-NMC, only one of them is required.)
ncdns is buildable as either an executable or a library. The executable is intended for integrating
.bit into a standard DNS recursive resolver like Unbound. In Whonix’s case, that doesn’t make much sense, since DNS resolution in Whonix is usually done by Tor. ncdns as a library is used by ncprop279, which is a Prop279 plugin that (when combined with StemNS, which interfaces with the Tor control port) allows
.bit resolution with Tor. I suspect that ncprop279 will make more sense for Whonix than ncdns as an executable. Either way, they need a Namecoin client (either Namecoin Core or Electrum-NMC) to be present.
I concur. Maybe reasonable to support as an optional configuration for users with unusually strong security requirements, in the distant future, but probably not a default recommended configuration, and probably not the first step.
There’s almost no code in the Tor Browser Nightly integration that depends on Firefox. Pretty much everything is interfacing with Tor rather than Firefox. It happened to end up in the Tor Browser packaging (as opposed to the Tor daemon packaging) for UX and practical reasons, but those reasons don’t matter for Whonix.
It should be possible to do this entirely on the Gateway, but I would be concerned about the risk of proxy leaks from Electrum-NMC. I did some brief testing of Electrum-NMC for proxy leaks and did not find any (and I assume there’s been significant testing of upstream Electrum for proxy leaks since it’s used in Tails and Whonix), but if there were such a proxy leak, having Electrum-NMC running on the Gateway would be a deanonymization hazard, since the network traffic it issues reveals which names are being looked up.
Interesting, I wasn’t aware that Tails used to support Monkeysphere and I2P. I intend to reach out to the Tails devs as well about this; I decided to reach out to Whonix first since Whonix is my daily driver and I’ve submitted patches to you before, whereas my familiarity with the Tails ecosystem is pretty minimal.
Parts of this could definitely be done as a generic Debian package (and I would definitely be in favor of that), but the parts that integrate with the Tor control port may need special consideration with respect to Whonix given the unique security-by-isolation requirements of Whonix.
This is definitely relevant to non-Tor usage, e.g. Kicksecure. For Whonix (and other Tor use cases), messing with
resolv.conf is not needed; resolve operations are hooked via the Tor control port, not the system DNS resolver.
For non-Tor usage (e.g. Kicksecure or standard Debian), the typical setup would not involve ncdns modifying
resolv.conf would be modified by a recursive resolver package (e.g. Unbound), and ncdns would place a file in
unbound.conf.d. AFAIK this works fine right now;
unbound.conf.d globbing is supported by Unbound, and the ncdns docs instruct to do it that way. (Presumably as we get ncdns packaged in Debian, the package will do that automatically.)
ncprop279 (as well as ncdns) doesn’t generate external network traffic; it only passes requests to Electrum-NMC (or Namecoin Core). Electrum-NMC produces external network traffic per lookup (and when downloading block headers), and supports Tor’s SOCKS port (with stream isolation via SOCKS username/password). Namecoin Core (if you decided to use it instead of Electrum-NMC) produces external network traffic when downloading the blockchain (and also supports Tor’s SOCKS port, with stream isolation via SOCKS username/password), but does not produce any network traffic on lookup operations (since Namecoin Core is able to cache the name database locally because it has the full blockchain available).
We don’t have a great rough implementation idea yet.
- Dedicated VM -> overkill.
- Namecoin on gateway -> leak risk. (But not higher than running in Tails.)
- Namecoin using
ControlPortin workstation -> difficult
Why not hook into system the DNS resolver too?
- No dedicated namecoin VM required.
- No leak risks.
Disadvantage: not stream isolated. Well, but system default DNS isn’t either.
(And before someone quotes me on that and asks (much) later what that is about, see https://www.whonix.org/wiki/Stream_Isolation)
Using that method, even the generic namecoin Debian package would work out of the box inside Whonix.
(With a small limitation I am happy to work on. Whonix might need to change to resolvconf of unbound (?) to support /etc/resolv.conf configuration drop-ins.
Why unbound? I haven’t looked into it. Is that a strong dependency? Or would resolvconf work too in principle? I imagine with resolvconf there could be two snippets.
Non-Tor use case:
- namecoin (virtual) IP drop-in
- real DNS drop-in
Whonix use case:
- namecoin (virtual) IP
- Whonix-Gateway IP
Once the first (1) resolver (namecoin) noticed “not a
.bit domain” it says “no” and the next entry (2) takes over.
Above might work well for system DNS with namecoin support inside Whonix?
But if Tor Browser enables namecoin by default inside Whonix that could be an issue? Because Tor Browser expects to talk to talk to a Tor that understands namecoin and stream isolation? If Tor Browser ships its own namecoin, I guess there is no way around the control port filtering anyhow without having limited functionality inside a Tor Browser that runs inside Whonix-Workstation?
Pondering this more… the primary risk of proxy leaks is from Electrum-NMC, since it’s the only component that intentionally opens external network connections. (StemNS only connects to the Tor control port, and ncprop279 only connects to the Electrum-NMC RPC port. StemNS communicates with ncprop279 via stdin/stdout.) However, Electrum-NMC doesn’t need to be in the same VM as StemNS+ncprop279.
So, an approach we could take here is that StemNS and ncprop279 run on the Gateway, and Electrum-NMC runs on the Workstation. StemNS will detect which IP the
STREAM event came from (i.e. the IP of the Workstation), and can instruct ncprop279 to connect to Electrum-NMC on that IP. This would require me to make some minor patches to StemNS (and maybe ncprop279), but that’s not a problem for me.
Hmm, this point may benefit from some more pondering too. As far as I can tell, the main threats we need to prevent are:
REDIRECTSTREAMon a stream where the
Targetdoesn’t have a
.bitsuffix. (Prevents a Namecoin vulnerability from affecting non-Namecoin domains.)
REDIRECTSTREAMfrom one Workstation on a stream where the
SOURCE_ADDRis a different Workstation. (Prevents a vulnerability in one Workstation from hijacking Namecoin lookups in other Workstations. Also avoids situations where two StemNS instances try to resolve the same stream.)
ATTACHSTREAMwith a nonzero
CircuitIDor with a non-null
HopNum. (Prevents a vulnerability in Namecoin from messing with how circuits are assigned to streams.)
ATTACHSTREAMon a stream with a
StreamStatusnot equal to
CONTROLLER_WAIT. (Prevents a vulnerability in Namecoin from DoSing local applications by causing their streams to disconnect.)
(3) can be easily prevented by standard onion-grater regex. The others are all dependent on knowing the stream status, which we could handle in 3 ways:
- onion-grater could cache all
STREAMevents, and check their status as part of the filtering of
ATTACHSTREAM. Perhaps by applying a regex whitelist to the
STREAMevent when choosing whether to filter
- onion-grater could send
GETINFOto Tor when it sees
ATTACHSTREAM, in order to fetch the current stream status, and use the result to determine whether to filter the command. Again, possibly by applying a regex whitelist to the
- Tor could add some optional arguments to
ATTACHSTREAMthat contain the extra status variables, which cause the command to be a NOP if the stream’s status doesn’t match the args; onion-grater could then apply standard regex whitelisting to those args.
(1) seems unpleasant since it makes onion-grater keep track of state. (2) seems relatively straightforward, but does slightly increase the complexity of onion-grater. (3) might be the simplest, but would require Tor to merge a patch. Tor has merged control protocol patches related to Namecoin use cases before, so it’s not out of the question that Tor could merge such a patch.
Wouldn’t this only work for applications that use the system DNS resolver? I.e. any application that uses a SOCKS port won’t have Namecoin resolution. That would be rather unfortunate.
My take is that losing stream isolation is a pretty bad privacy hit; I’d be a lot happier about the approaches described above. Running StemNS and ncprop279 in the Gateway while running Electrum-NMC in the workstation seems to me to be the most straightforward approach, though if for some reason you strongly prefer another approach (e.g. one of the control port filtering methods I described), I’m not ruling that out.
In Tor Browser Nightly, the Namecoin support can be toggled with an environment variable. I suspect that disabling Tor Browser’s Namecoin support in the Workstation via environment variable, while enabling Namecoin on the Gateway’s Tor instance, will mostly work fine; Namecoin resolution should work approximately the same way. There may be a few rare edge cases that would need to be handled, but I expect they would be manageable (especially because the code in the Tor Browser integration that might produce such edge cases hasn’t been written yet, and when I write that code, I should be able to do it in a way that will minimize the impact on Whonix).
(Skipped replying to a few paragraphs that I suspect are less applicable given my reply; let me know if you still want me to reply to those.)
That sounds good!
Keeping as much away of the gateway + onion-grater modifications sounds good.
From Whonix (and perhaps Tails) perspective this might be ideal since then complexity is abstracted in Tor, not Whonix.
I hope this would be considered during packaging.
I’ve filed a Tor issue about adding this feature to the Tor control protocol. Nick has replied and appears open to it. So, looks like that is the most suitable path forward. I will work on implementing that patch; not sure how long it’ll take me. (I don’t enjoy writing C, so it may not happen super quickly.)
ncprop279 is the component that would need a config option set to use Electrum-NMC in another VM, and ncprop279 already supports that config option (and supports
conf.d), so I think this should be pretty easy.