UX issues of v3 onion services

We are looking for strategies that do not involve standard central registries like DNS records for onion operators. We maybe have funding for this but we're not sure.

Q: Are we looking for users to type these in, or are we just looking for telling users whether two onion names are the same?

A: I think we are focussing on the first one.

There was text in the Cloudflare blog post that said onion names are like IP addresses, and we're basically lacking the DNS to make them more useful. I have identified the following possible avenues forward. They all kind of suck.

Table of criteria:

  1. hijacking resistance
  2. usability
  3. engineering effort
  4. state on client system
  5. global names
  6. censorship
  7. enumeration
  8. phishing resistance

General candidates:

  • blockchain [fails laugh test; `have you considered cyber?']
    • namecoin
    • blockstack?
    • handshake
    • ENS

Kind of all suck. Hard to bake a blockchain into Tor.

  • Secure name system research field is not going very far.
    • gnunet kind of exists, GNS
      • web of trust
      • public keys, references
      • works in theory but not really according to the people I've talked to and so you kind of have to rebuild the whole thing to use it

Usability is not so good. Requires passing long strings to users for GNS root; then you use, e.g., facebook.alice, where alice refers to the key for alice's GNS root.

Kind of like SPKI/SDSI, or UUCP for onions.

gnunet people report it doesn't work and isn't maintained.

Q: Something that's crufty and a mess might still have parts that work -- something that doesn't exist at all because it's dissertationware won't work because it doesn't exist at all. Should we reject it because it's crufty, or because of the design?

A: Well, there's a paper but it isn't really implemented or something.

  • https-everywhere: abuse extension to add onions in there
    • communities can publish rulesets of onions
    • called darkweb-everywhere but it didn't go anywhere, so it's more like darkweb-nowhere now
  • encrypted bookmarks
  • bespoke Tor naming authority
  • i2p has a .names file on some server somewhere and some people sign it and people use it and it kind of works and we have nothing -- we have 56 characters of onions.

It's kind of like a global list checked into version control.

Q: Do any of these systems cover the Certificate Transparency property where anyone asserting ownership of a name -- or hijacks a name -- has to publish a record that anyone can verify.

QQ: Do you like Certificate Transparency so much?

Q: ...It's a thing.

So, how about we use a variant of https-everywhere to let communities publish their own lists of onions? For example, we can have Alec Muffet write his own list, and then everyone can use it.

Q: It's like /etc/hosts?

A: Well, a signed /etc/hosts with an update channel. You can provide

a scope that limits certain sources, e.g. you can scope the Freedom of the Press Foundation update channel so it can only provide things for *.freedom.tor.

Q: Can you deny http traffic? Do onion traffic only?

A: Yes.

Q: How does https-everywhere actually solve any of the problems?

A: It solves UX problems because extensions are easy to load into a browser. It doesn't solve hard problems of global naming business.

Philip Winter had a paper on how Tor users use onions. They found >50% of them use bookmarks. Only 9% were afraid that keeping state on their computer might damage them. Basically it showed that people are willing to use nonperfect solution for this problem.

Q: Usability point about https-everywhere. Say user types in facebook.tor. If we just make an https-everywhere toolset, URL changes from facebook.tor to facebookcorewwwi.onion (or the 56-character v3 one), which can be confusing.

A: We'll have this problem anyway with the onion-location header that we're planning to do. If we control the browser, we can make this experience less surprising.

Similar to problem with trusting a bad CA.

Typos? Say the list has duckduckgo and duckducksgo.

DNS leaks. If you have a .onion address, currently Firefox makes no DNS requests. If we invent a new .tor namespace, we need browsers to also avoid new DNS requests.

If we build a mechanism for Facebook to prevent phishing by reclaiming any name that has Facebook, then we've invented a censorship mechanism. If we don't, then we allow phishing.

Back to verification. Maybe next to the onion address. I joked about replacing 56 characters by emojis. This is only half a joke: visual fingerprints. Put them in the URL bar; put them in the bookmark links. See old proposal.

Concern about disparate rulesets for different communities: enables fingerprinting by watching how a user's browser responds to foo.tor, bar.tor, and baz.tor when all three appear differently in different communities.

Q: Does https-everywhere rewrite, e.g., img URLs, or just in the URL bar?

A: It doesn't rewrite page contents, but it rewrites URL fetches. So yes, this attack works.

Q: Blockchain solves ordering [between mutually untrusting parties]: entry A < entry B. Trusted clock also solves it. There isn't any trusted timestamp that works as a blockchain. [Q: Secure random? A: OK, maybe we do have a trusted timestamping service.] Can we put a timestamp in the URL using a trusted timestamping service? Gives a first-come-first-serve naming system.

A: That's kind of what a bespoke Tor naming authority would work.

Q: If you don't want to deliver an entire blockchain to the tor client because that's absurd, you could periodically checkpoint it into a bundle for the Tor Project to distribute on some update channel?

A: We don't want the Tor Project to be the authority for naming. With https-everywhere, it would not be in the Tor Project's hands -- users would get it from the wild west of the internet. The authority would be in Alec Muffet's hands.

Q: Would Tor Browser bundle all of the keys for all these communities' specific https-everywhere rulesets?

A: I don't know!

This all sucks! I don't know.

Q: What about encrypted bookmarks?

A: Well, we already have unencrypted bookmarks. I'm not sure the encrypted part gives that much. Maybe it prevents the police from decrypting your bookmarks when they come to your door.

Q: But -- except for ??? -- it checks off a lot of boxes.

Q: It seems to me you're looking for two things: to find out if the people here would be accepting of a solution that's not perfect; if so, to prioritize the criteria.

Q: Can we separate this into the _positive_ applications,

  • application: the positive operations we want to be able to do, like 'I want to be able to tell my friend about an onion service';
  • threat model: what are the powers of the adversary, like police can bust down door and read bookmarks, sibyl attack on directory services, etc.;
  • security properties: what do we want to guarantee adversary can't do to users?

Q: How well do we trust certificate authorities? Can we just embed it in TLS certificates, like's certificate mentions the .onion?

A: Whatever builds into the existing naming system is basically out of scope for this right now.

Q: Can we scan the Alex top 1m sites, and see what has an to enumerate their onion addresses?

A: Maybe?

Q: For places that have registered domain names, we have an approach, but that was off the table from the premise here...

[back and forth]

Q: Can we break this down into user profiles? For example, Facebook's use case -- where they have a name in the usual namespace -- is adequately served by DNS, HTTPS CAs, and alt-svc. But onionshare is a completely different beast.

A: Yes!

Q: Updates! Every SecureDrop system needed to be updated after heartbleed. How to solve? We can put a redirect at

A: But...then you're relying on HTTPS CA system.

If anyone wants to talk https-everywhere more, there's a session tomorrow morning.

Some of this depends on whether we get funding or not!

Last modified 2 years ago Last modified on Oct 1, 2018, 6:05:18 AM