Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#18119 closed enhancement (wontfix)

.onion domain names can be really short

Reported by: azazar Owned by:
Priority: Medium Milestone: Tor: very long term
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs needs-proposal
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

It's quite easy now to use vanity generator to generate .onion domain names such as aaaaaaaaaa<6 random chars>.onion . If onion router will be able to resolve any currently invalid, shorter domains, such as zxczxc.onion to aaaaaaaaazxczxc.onion - we'll have have domains, that anyone can actually remember and those are much more convenient.

Child Tickets

Attachments (1)

tor_short.patch (3.9 KB) - added by azazar 4 years ago.
patch to resolve short .onion domains (eg xxxyyy.onion to xxxyyyaaaaaaaaaa.onion)

Download all attachments as: .zip

Change History (18)

comment:1 Changed 4 years ago by azazar

sample domain for convenient testing: taopopb7xaaaaaaa.onion

shortened: http://taopopb7x.onion/
full backwards-compatible: http://taopopb7xaaaaaaa.onion/

Last edited 4 years ago by azazar (previous) (diff)

Changed 4 years ago by azazar

Attachment: tor_short.patch added

patch to resolve short .onion domains (eg xxxyyy.onion to xxxyyyaaaaaaaaaa.onion)

comment:2 Changed 4 years ago by azazar

Milestone: Tor: 0.2.9.x-finalTor: unspecified

comment:3 Changed 4 years ago by teor

Keywords: tor-hs added; tor domains removed
Milestone: Tor: unspecifiedTor: very long term
Severity: MajorNormal
Status: newneeds_revision
Version: Tor: unspecified

While this is a user-interface improvement, I'm not sure that it's the most secure way of solving this issue. Have you heard about OnionNS?

Are you aware of Tor Proposal 224 - next-generation hidden services?
(Names will be even longer, and therefore it will be harder to produce vanity names.)

As far as the patch goes, please don't add the extra line in .gitignore.
Otherwise, it looks plausible, I'll wait to do a full review until we decide if we want this feature.

comment:4 Changed 4 years ago by yawning

Keywords: needs-proposal added

Inclined to NACK due to 224 making this totally worthless in any meaningful manner, and before this has a chance of getting merged despite my objections, a change like this will need to go through the proposal process.

I don't think we use alloca() in the code, and it feels gratuitious when a pair of statically sized buffers will suffice.

Blindly truncating down addresses assuming the shorted format when doing the comparsion probably leads to odd things happening to existing deployed HSes that happen to have a stream of as at the end.

comment:5 in reply to:  4 Changed 4 years ago by teor

Replying to yawning:

Blindly truncating down addresses assuming the shorted format when doing the comparsion probably leads to odd things happening to existing deployed HSes that happen to have a stream of as at the end.

There are a few spare bits in prop224 HS addresses, one of them could be used for "short address". But I can't see a way of fixing this with the current address format, because it uses all its bits.

comment:6 Changed 4 years ago by dgoulet

Resolution: wontfix
Status: needs_revisionclosed

I'll NACK this also. It's true we can improve on the *UI* side like teor mentioned but this change makes it baked in tor entering a slippery slope of security issues and increasing attacker surface to trick users.

And yes, next gen hidden service (prop224) will render this useless. There are ideas running around on offering a way for users to use smaller addresses in prop224 which is a tradeoff in security vs usability. Basically, it looks a bit like this proposed solution where you would use a smaller portion of the key and if it matches the start of a descriptor address on the HSDir, we would return it. But this would need either a proposal on its own or modification to prop224 before we could consider implementation.

We should open a specific ticket for smaller address idea _specifically_ for proposal 224 and detail the mechanics in there. So closing this, I see two NACKs now and a very uncertain diplomat teor :).

comment:7 in reply to:  4 ; Changed 4 years ago by azazar

Replying to yawning:

Blindly truncating down addresses assuming the shorted format when doing the comparsion probably leads to odd things happening to existing deployed HSes that happen to have a stream of as at the end.

Actually, this patch is backwards-compatible, all existing addresses should work as they did before. It translates only shortened addresses. What kind of odd things could happen?

Last edited 4 years ago by azazar (previous) (diff)

comment:8 Changed 4 years ago by cypherpunks

I think we shouldn't shorten .onion addresses, but instead we should longer them. Just use a subdomain.
service_friendly_name.the_hash.onion

comment:9 in reply to:  7 ; Changed 4 years ago by teor

Replying to azazar:

Replying to yawning:

Blindly truncating down addresses assuming the shorted format when doing the comparsion probably leads to odd things happening to existing deployed HSes that happen to have a stream of as at the end.

Actually, this patch is backwards-compatible, all existing addresses should work as they did before. It translates only shortened addresses. What kind of odd things could happen?

Some existing addresses have one or more "a"s at the end.

comment:10 in reply to:  9 ; Changed 4 years ago by yawning

Replying to teor:

Actually, this patch is backwards-compatible, all existing addresses should work as they did before. It translates only shortened addresses. What kind of odd things could happen?

Some existing addresses have one or more "a"s at the end.

I wasn't thinking clearly when I wrote that, those would work in the "get truncated down to the 'short' form then compared" sense. Which is odd and unexpected, but probably fine.

I stand by the NACK though (One additional unintended consequence of this is someone accidentally going to spacebookcorewww.onion would actually attempt to get descriptors instead of failing at the validation stage).

comment:11 in reply to:  10 ; Changed 4 years ago by azazar

Replying to yawning:

I stand by the NACK though (One additional unintended consequence of this is someone accidentally going to spacebookcorewww.onion would actually attempt to get descriptors instead of failing at the validation stage).

spacebookcorewww.onion won't be translated at all, since it already contains 16 characters. And the chance of address collision for shortened names is absolutely equal to complete 16-character addresses collision chance(you'll have to use vanity generator for getting shorter names anyway).

Last edited 4 years ago by azazar (previous) (diff)

comment:12 in reply to:  6 Changed 4 years ago by azazar

Replying to dgoulet:

I'll NACK this also. It's true we can improve on the *UI* side like teor mentioned but this change makes it baked in tor entering a slippery slope of security issues and increasing attacker surface to trick users.

What kind of security issues? I didn't notice any. BTW: making names shorter allows user to identify fishing sites.

Last edited 4 years ago by azazar (previous) (diff)

comment:13 in reply to:  11 ; Changed 4 years ago by yawning

Replying to azazar:

spacebookcorewww.onion won't be translated at all, since it already contains 16 characters. And the chance of address collision for shortened names is absolutely equal to complete 16-character addresses collision chance(you'll have to use vanity generator for getting shorter names anyway).

Sigh. It was an example that I figure would have been obvious, but fine I'll be explicit and use a real domain.

Entering facebookcorewww.onion should fail, and ideally without hitting up the HSDirs. (The real HS being facebookcorewwwi.onion).

comment:14 in reply to:  13 ; Changed 4 years ago by azazar

Replying to yawning:

Replying to azazar:

spacebookcorewww.onion won't be translated at all, since it already contains 16 characters. And the chance of address collision for shortened names is absolutely equal to complete 16-character addresses collision chance(you'll have to use vanity generator for getting shorter names anyway).

Sigh. It was an example that I figure would have been obvious, but fine I'll be explicit and use a real domain.

Entering facebookcorewww.onion should fail, and ideally without hitting up the HSDirs. (The real HS being facebookcorewwwi.onion).

It will fail, unless someone is able to bruteforce secret for facebookcorewwwa.onion(which is resolved from facebookcorewww.onion). And it isn't easier, than bruteforcing hash for facebookcorewwwi.onion(difficulty of those tasks are exactly equal).

Last edited 4 years ago by azazar (previous) (diff)

comment:15 in reply to:  14 ; Changed 4 years ago by yawning

Replying to azazar:

It will fail, unless someone is able to bruteforce secret for facebookcorewwwa.onion(which is resolved from facebookcorewww.onion). And this isn't easier, than bruteforcing hash for facebookcorewwwi.onion(difficulty of those tasks are exactly equal).

It will fail, after querying all of the HSDirs for a non-existent hidden service. This is a waste of network resources.

comment:16 in reply to:  15 ; Changed 4 years ago by azazar

Replying to yawning:

Replying to azazar:

It will fail, unless someone is able to bruteforce secret for facebookcorewwwa.onion(which is resolved from facebookcorewww.onion). And this isn't easier, than bruteforcing hash for facebookcorewwwi.onion(difficulty of those tasks are exactly equal).

It will fail, after querying all of the HSDirs for a non-existent hidden service. This is a waste of network resources.

And how much extra resources that could "waste"? Milliseconds of CPU time and maybe one or several kilobytes of network traffic occasionally? Is that more important, than user's convenience?

Last edited 4 years ago by azazar (previous) (diff)

comment:17 in reply to:  16 Changed 4 years ago by teor

Replying to azazar:

Replying to yawning:

Replying to azazar:

It will fail, unless someone is able to bruteforce secret for facebookcorewwwa.onion(which is resolved from facebookcorewww.onion). And this isn't easier, than bruteforcing hash for facebookcorewwwi.onion(difficulty of those tasks are exactly equal).

It will fail, after querying all of the HSDirs for a non-existent hidden service. This is a waste of network resources.

And how much extra resources that could "waste"? Milliseconds of CPU time and maybe one or several kilobytes of network traffic occasionally? Do you think, that it's more important, than user's convenience?

I don't think we'll be taking this code.

To get community consensus on a significant change like this, people write proposals and post them to the tor developer mailing list.

Given the number of outstanding hidden service proposals, and the availability of other onion "friendly name" systems, I'll warn you in advance that it's unlikely to happen.

Note: See TracTickets for help on using tickets.