4 ms·

I'm curious why they decided on a "special-use domain name" instead of something like "onion://hash".

by cmrx64 10y ago

vortico 10y ago
This committee recognizes what already exists. onion://hash is not used because .onion domains are not different protocols (they're still http) but are a specially allocated space of hostnames representing the "addresses" of Tor servers.
- niij 10y ago
  .onion domains can use any service they like and are not limited to just HTTP. These are all valid: ssh://abc123.onion ftp://abc123.onion https://abc123.onion https://abc123.onion
eriknstr 10y ago
It was a long time ago that TOR chose to do so. I also think TLD makes sense anyway. TOR is a network and the protocol of the traffic that is relayed through it is independent of the transport.
AgentME 10y ago
Onion addresses describe a host that can be talked to via TCP, not just HTTP.
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.
chungy 10y ago
It is extremely useful for an onion address to just define a plain old TCP socket, rather than imply HTTP. An onion address is just that... an anonymous connection to some server, somewhere in the world. While you might be unaware of where the service is operated from, it could be the exact opposite: maybe you just started an ssh server on your desktop and would like to access it remotely where ssh might be monitored or blocked -- despite ssh itself being encrypted, making a connection and the lifespan of the connection tell quite a lot about your habits. Or maybe you decide to visit China for a weekend... Hell, or maybe you're buried behind multiple NATs/firewalls and just need an easy way to poke from the outside (I've done this, in corporate environments where you can run your own VMs and such)
- cmrx64 10y ago
  I'm not sure why so many people seem to think that I'm implying anything about HTTP. "onion" would be fine as a URI scheme I think. Different programs would interpret it differently, which is obviously bad, and using a special-use domain name lets it slot seamlessly into the usual URI system as just a different sort of host specifier, which is obviously better, lacking something like nested URIs (http://www.it.uc3m.es/muruenya/papers/nested_uris_euromicro05.pdf http://www.it.uc3m.es/muruenya/papers/nested_uris_euromicro0...), which never became a thing.

I'm curious why they decided on a "special-use domain name" instead of something like "onion://hash".

by cmrx64 10y ago

I'm curious why they decided on a "special-use domain name" instead of something like "onion://hash".

This committee recognizes what already exists. onion://hash is not used because .onion domains are not different protocols (they're still http) but are a specially allocated space of hostnames representing the "addresses" of Tor servers.

niij 10y ago
.onion domains can use any service they like and are not limited to just HTTP. These are all valid: ssh://abc123.onion ftp://abc123.onion https://abc123.onion https://abc123.onion

eriknstr 10y ago

It was a long time ago that TOR chose to do so. I also think TLD makes sense anyway. TOR is a network and the protocol of the traffic that is relayed through it is independent of the transport.

AgentME 10y ago

Onion addresses describe a host that can be talked to via TCP, not just HTTP.

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.

chungy 10y ago

It is extremely useful for an onion address to just define a plain old TCP socket, rather than imply HTTP. An onion address is just that... an anonymous connection to some server, somewhere in the world. While you might be unaware of where the service is operated from, it could be the exact opposite: maybe you just started an ssh server on your desktop and would like to access it remotely where ssh might be monitored or blocked -- despite ssh itself being encrypted, making a connection and the lifespan of the connection tell quite a lot about your habits. Or maybe you decide to visit China for a weekend... Hell, or maybe you're buried behind multiple NATs/firewalls and just need an easy way to poke from the outside (I've done this, in corporate environments where you can run your own VMs and such)

cmrx64 10y ago
I'm not sure why so many people seem to think that I'm implying anything about HTTP. "onion" would be fine as a URI scheme I think. Different programs would interpret it differently, which is obviously bad, and using a special-use domain name lets it slot seamlessly into the usual URI system as just a different sort of host specifier, which is obviously better, lacking something like nested URIs (http://www.it.uc3m.es/muruenya/papers/nested_uris_euromicro05.pdf http://www.it.uc3m.es/muruenya/papers/nested_uris_euromicro0...), which never became a thing.