|
|
== 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](https://lists.torproject.org/pipermail/tor-dev/2015-August/009302.html).
|
|
|
|
|
|
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 facebook.com'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 example.com/.well-known/tor-addresses 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 facebook.com 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 https://theintercept.com/securedrop.
|
|
|
|
|
|
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! |