Opened 5 months ago

Last modified 4 weeks ago

#30558 assigned defect

Namecoin support for onion sites in Tor Browser

Reported by: arthuredelstein Owned by: JeremyRand
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: pili, gk, antonela, asn, boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The problem
Onion domains are generally almost impossible for humans to remember. Specifically, they are very long and consist of a series of random characters.

v2 domains look like this:

and v3 domains look like this:

So, while onion domains are secure and decentralized, they are not human-meaningful, and thus fail to satisfy all three desired properties described in Zooko's triangle.

Proposed solution
Namecoin offers a solution for Zooko's triangle. Domains are registered in a decentralized manner, can be remembered by humans, and are secure. A Namecoin (.bit) domain looks like this:

The .bit domains can be pointed to a unique .onion domain. So the user needs only to enter http://federalistpapers.bit and they will be taken to the appropriate onion site (in this case, http://7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion)

The task consists of writing patches for Tor Browser that integrates a Namecoin lookup client, such that when a user enters a .bit domain name the browser is connected to the underlying .onion site. In the address bar, the entered address including a .bit domain will continue to be shown, and the .onion domain will be indicated on the circuit display.

Initially, the patches can be integrated into Tor Browser Nightly. If testing is successful, I hope it could progress to Tor Browser alpha and eventually stable.

Comparison to other approaches
There are several promising approaches to allowing human-meaningful aliases to onion sites. However, they don't fully solve Zooko's triangle:

  • HTTPS Everywhere: Aliases are under central control by the addon maintainer.
  • Bookmarks/Petnames: Aliases are not global.
  • Alt-Svc/Onion-Location: Aliases require first connecting through a centralized ICANN domain.

I think Namecoin is especially promising because it can be globally registered and maintained securely by the onion site operator, without any centralized permission. Thus the properties of security and decentralization offered by .onion domains are shared by .bit domains.

There are some challenges:

  • Historically, Namecoin lookup has been slow and required cumbersome downloads. Jeremy has made major progress in reducing the footprint.
  • Registering a Namecoin domain requires downloading specialized software and is not anonymous without special precautions. Future work (out of scope here) could include building documentation and/or software tools to allow onion operators to easily and anonymously register a .bit domain and point it to a .onion domain.

Child Tickets

Change History (6)

comment:1 Changed 5 months ago by gk

Cc: gk added; GeKo removed
Parent ID: #30029

Note, even though this has #30029 as parent ticket, it is not related to our sponsor work. Thus, I am unparenting the ticket, to make that clear (i.e. #30029 is not blocking on this ticket).

Last edited 5 months ago by gk (previous) (diff)

comment:2 Changed 5 months ago by cypherpunks

HTTPS Everywhere: Aliases are under central control by the addon maintainer.

NO, HE supports different streams.

comment:3 Changed 4 months ago by boklm

Cc: boklm added

comment:4 Changed 3 months ago by JeremyRand

Early branch: https://notabug.org/JeremyRand/tor-browser-build/src/namecoin (you want the namecoin branch).

The 3 most major shortcomings in its current state are:

  1. ncprop279 isn't built locally, but instead is pulled from a binary release on namecoin.org. This is because ncprop279 currently needs a different version of the Go compiler than tor-browser-build uses, so it needs to be built in its own tree. The binary that's being pulled in is (in theory) reproducible with rbm (via the ncdns-repro repository), so it's not a security issue, but it makes the build workflow a lot more annoying than it should be. I'm in the process of getting a patch merged to Namecoin that will fix this issue; I expect it to be resolved in less than a month.
  2. Electrum-NMC is pulled in via the Python source code tarball on namecoin.org. That tarball contains source code from various Python dependencies of Electrum. It would be a lot better to pull in those dependencies from their upstream source (either Git or tarballs), and then combine them with Electrum-NMC's source (from Git). I'm in the process of implementing this; I expect it to be resolved in less than 2 months.
  3. This branch uses an official Electrum-NMC release rather than the Electrum-NMC branch I used in the live demo. The live demo branch has some patches that make initial syncup much faster (nearly instant), whereas the official release will probably take about 5 minutes to do initial syncup. Most of the patches for faster syncup are now undergoing review by upstream Electrum; this has already yielded much better code quality than the live demo branch (shocking, I know -- the Electrum devs know their own codebase better than I do!), but it does mean there's some delay in getting everything merged. I think it's likely that a lot of this code will be merged upstream in the next 2-3 months.

Anyway, while this isn't production-ready in any way, I figure it's a good idea to post it here for transparency purposes. If anyone wants to play around with it, build a nightly of Tor Browser (must be 64-bit Linux), and set the environment variable TOR_ENABLE_NAMECOIN=1 before you run Tor Browser. .bit and .bit.onion sites should "just work" (modulo the initial syncup time, see above). Right now .bit sites can point to IP address or onion services, and Namecoin TLS is not part of this patch. Prior to a release, I intend to disable IP addresses, so .bit can only point to a .onion, and we can evaluate how to do IP+TLS securely at a later date. Be sure to check out the awesome circuit display when you're viewing a Namecoin onion service! (Kudos to Arthur for the Torbutton patch that does this.)

Cheers!

comment:5 Changed 4 weeks ago by JeremyRand

ncprop279 isn't built locally, but instead is pulled from a binary release on namecoin.org.

Updated branch at https://notabug.org/JeremyRand/tor-browser-build/src/namecoin (commit hash accff2aff645c7dac487e9acd0cbd43fa8372b12). ncprop279 is now built locally.

The updated branch also disables --detach if Namecoin is enabled, which allows Namecoin to be used when double-clicking the Tor Browser launcher icon. (I noticed that this was broken in the previous branch during the Stockholm meeting.)

More updates should be coming fairly soon.

comment:6 Changed 4 weeks ago by JeremyRand

Electrum-NMC is pulled in via the Python source code tarball on namecoin.org. That tarball contains source code from various Python dependencies of Electrum. It would be a lot better to pull in those dependencies from their upstream source (either Git or tarballs), and then combine them with Electrum-NMC's source (from Git).

Updated branch at https://notabug.org/JeremyRand/tor-browser-build/src/namecoin (commit hash 4b23a0490f49e9c08c63ae5ab3c70d66be84115e). Electrum-NMC and its dependencies are now built locally from source, subject to a few exceptions:

  1. PyQt isn't built at all. This doesn't matter for Tor purposes since Tor isn't going to use the PyQt GUI from Electrum-NMC.
  2. Locales aren't built at all. Again, this doesn't matter for Tor purposes since the Electrum-NMC UI isn't going to be user-facing and therefore doesn't need to be translated.
  3. Protobuf definitions aren't built from source, instead the pre-compiled Protobuf definitions that Electrum-NMC distributes are used. I'm fairly sure this isn't a problem since Protobuf is (AFAICT) only used in Electrum-NMC for the Payment Protocol, and that's not functionality that Tor will ever need to touch. In fact, I suspect that the Protobuf dependency can be completely ripped out of Electrum-NMC for Tor distribution, which will also reduce the final binary size noticeably.

Prior to a release, I intend to disable IP addresses, so .bit can only point to a .onion

This is implemented in 4b23a0490f49e9c08c63ae5ab3c70d66be84115e as well, though I haven't tested that change very thoroughly yet.

I'm hoping to have some additional updates within the next week or two.

Note: See TracTickets for help on using tickets.