3 ms·

Because https://.onion https://.onion and ftps://*.onion are different. And it lets you do things like tor2web by just appending a DNS domain to the end of th

by zrm 10y ago

Because https://*.onion https://*.onion and ftps://*.onion are different. And it lets you do things like tor2web by just appending a DNS domain to the end of the onion domain, without requiring any special client support. And more things break on unexpected protocols than unexpected names.

cmrx64 10y ago
That makes sense. I wasn't aware of the details, but looking into it now, "onion"/hidden services are a way of establishing tor circuits which are then used normally. Thanks!
greglindahl 10y ago
*.onion.link is an example of tor2web
NL807 10y ago
Two URL schemas could've been easily specified to accommodate the two scenarios: httpo://... and ftpo://...
kaoD 10y ago
Maybe https+onion://, ftps+onion://, etc.? .onion being a special-cased TLD is calling for unexpected privacy leaks.
- jrochkind1 10y ago
  Or even `onion:http//some.hostname` -- would that be allowed by generic URI spec? Not sure, I think so?
- Ajedi32 10y ago
  As I understand it, currently _any_ protocol can be routed to a `.onion` TOR hidden service using a SOCKS proxy. So services don't necessarily even need to be aware of TOR, and can just use it as an underlying transport so long as they're capable of routing traffic and DNS requests through SOCKS. You wouldn't be able to do that if you just started making up protocol names like that; your FTP client doesn't know how to handle the `ftps+onion://` protocol. (But it can handle `ftps://somedomainhash.onion/` over a TOR-aware SOCKS proxy just fine.) This advantage is entirely negated though by this line in the new spec: "Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup." So you definitely have a valid point. If they don't want to allow applications that don't explicitly support TOR to connect to `.onion` addresses, why not just make up new protocols that existing applications don't support?
  - zrm 10y ago
    > "Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup." The RFC is still a "Proposed Standard" and that sentence is probably a mistake. Even applications that are designed to use Tor like the Tor Browser don't "implement the Tor protocol", tor implements the Tor protocol and other applications use tor via SOCKS. Or not even that now that there are things like torify. The problem is there is a trade off between a) applications that know nothing of Tor leaking the onion name lookups from people who actually need anonymity into the public DNS when Tor is not installed or configured correctly, and b) breaking things for people who want the widest variety of application support via Tor, who aren't interested in anonymity and are only using it for e.g. NAT traversal. (The Tor people like to encourage the second group because more users improves overall anonymity.) A possible solution is Tor providing a particular innocent name that will resolve via Tor but not via public DNS, and then applications that can't resolve that name should not try to resolve any other onion names, and DNS caches like dnsmasq should by default return NXDOMAIN for that name without forwarding the query.

Because https://*.onion https://*.onion and ftps://*.onion are different. And it lets you do things like tor2web by just appending a DNS domain to the end of th

by zrm 10y ago

cmrx64 10y ago

That makes sense. I wasn't aware of the details, but looking into it now, "onion"/hidden services are a way of establishing tor circuits which are then used normally. Thanks!

greglindahl 10y ago

*.onion.link is an example of tor2web

NL807 10y ago

Two URL schemas could've been easily specified to accommodate the two scenarios: httpo://... and ftpo://...

kaoD 10y ago

Maybe https+onion://, ftps+onion://, etc.? .onion being a special-cased TLD is calling for unexpected privacy leaks.

jrochkind1 10y ago
Or even `onion:http//some.hostname` -- would that be allowed by generic URI spec? Not sure, I think so?
Ajedi32 10y ago
As I understand it, currently _any_ protocol can be routed to a `.onion` TOR hidden service using a SOCKS proxy. So services don't necessarily even need to be aware of TOR, and can just use it as an underlying transport so long as they're capable of routing traffic and DNS requests through SOCKS. You wouldn't be able to do that if you just started making up protocol names like that; your FTP client doesn't know how to handle the `ftps+onion://` protocol. (But it can handle `ftps://somedomainhash.onion/` over a TOR-aware SOCKS proxy just fine.) This advantage is entirely negated though by this line in the new spec: "Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup." So you definitely have a valid point. If they don't want to allow applications that don't explicitly support TOR to connect to `.onion` addresses, why not just make up new protocols that existing applications don't support?
- zrm 10y ago
  > "Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup." The RFC is still a "Proposed Standard" and that sentence is probably a mistake. Even applications that are designed to use Tor like the Tor Browser don't "implement the Tor protocol", tor implements the Tor protocol and other applications use tor via SOCKS. Or not even that now that there are things like torify. The problem is there is a trade off between a) applications that know nothing of Tor leaking the onion name lookups from people who actually need anonymity into the public DNS when Tor is not installed or configured correctly, and b) breaking things for people who want the widest variety of application support via Tor, who aren't interested in anonymity and are only using it for e.g. NAT traversal. (The Tor people like to encourage the second group because more users improves overall anonymity.) A possible solution is Tor providing a particular innocent name that will resolve via Tor but not via public DNS, and then applications that can't resolve that name should not try to resolve any other onion names, and DNS caches like dnsmasq should by default return NXDOMAIN for that name without forwarding the query.