Handle Both Types Of Onion Service Address

[cretz]

Right now it appears /onion is a fixed size which likely relates to Tor v2 onion service addresses. However, there is a longer v3 onion service address that is supported. Please either make a new protocol name for v3 or remove the size restriction on /onion.

[lidel]

Additional context:

• Working samples for v2 and v3 can be found at riseup.net#riseups-tor-onion-services
• Vanity address generator for v3: https://github.com/cathugger/mkp224o

[cretz]

I also have a lib. It includes some helpers that can convert keys to onion service IDs (and back for v3). Not sure it's useful to this project though. Both keys are base32'd...v2 keys are 16 chars (first 10 bytes of sha1'd rsa 1024 pub key) and v3 keys are 56 chars (32 byte ed25519 pub key + two bytes of sha3-256'd checksum + single version byte for total of 35 bytes).

[cretz]

Also, when calling listen with an onion address, it should be ok to not provide the onion service ID and it should be ok to not provide the port (or port 0 to be compatible w/ net.Listen). Asking Tor to create the key pair and/or choose the port is a very normal thing. So /onion/ (or maybe /onion/: or maybe /onion/:0) should be allowed, as should /onion/:100 or /onion/mylowercasebase32 or whatever. Similarly for listening, though I am not familiar enough to know whether this is already supported, since onion is a proxy, it should be able to chain tcp, e.g. /onion//ip4/127.0.0.1/tcp/1234 which says to the transport impl: "create a regular tcp listener on localhost and port 1234 and expose it via a tor onion service of a randomly generated service name and randomly chosen port".

Having said the above and noticing that you can listen on a random ID and port, /onion becomes ambiguous for v2 and v3 (it's an option you pass to Tor on ephemeral onion service creation). So maybe this does need to be /onion3 or something.

[ghost]

We should probably make these separate multiaddr schemes, e.g. /onion2 and /onion3, with fixed length each (similar to /ip4 and /ip6). Deriving the v2/v3 distinction based on the value length isn't a good idea.

[ghost]

Adding the help wanted label here -- this is relatively easy to do, just duplicate some of the existing /onion code and name it /onion3.

I don't think we should rename /onion itself to /onion2. We should have named it /onion2 to begin with, but now that it's there, we should just stick with it. Obviously it was already versioned on Tor's side -- silly oversight on our part.

[eyedeekay]

I'm working on doing this as part of some work for a company, and I think I have it, but can someone explain to me how the protocol argument sizes work? I'm seeing ipv4 has 32 bits, and the protocol in libp2p has 32 bits. ipv6 has 128 bits, and the protocol in libp2p has 128 bits. But onionv2 has 80 bits, and the protocol has 96 bits? I am sure I must be missing something important here.

[Stebalien]

Ah. So, it looks like onion addresses in go-ipfs include a port. That's where the extra two bytes come from (big endian port number appended to the address).

With TCP/IP, we have two components /ip4/.../tcp/.... However, specifying /onion/.../tcp/... doesn't really make sense as we're not really speaking TCP over onion. Instead, we're speaking onion over TCP (and I'm not sure where the port number comes in, really...).

[lidel]

Potential reason we have an explicit onion-port: Onion Service (private key) can expose multiple ports.

[cretz]

Could also be because, at least when specified at listen/bind time, the local port for a TCP listener can be different than the exposed port for the onion service.

[eyedeekay]

Thanks for your help, I've got a better handle on how it works now. I'm going to re-read the contributing documents and send up my changes.

[Stebalien]

@eyedeekay has fixed this.