Re: [tor-dev] Proposal 204: Subdomain support for Hidden Service addresses
On Fri, Jul 6, 2012 at 10:23 AM, <ale@incal.net> wrote:
Hello!
As discussed with a few people at the Florence Hackfest, here's a quick proposal for subdomain support on Hidden Service addresses. The implementation seems pretty straightforward (a patch will follow).
Please forgive me if the proposal is missing something, or isn't using the proper Tor-specific technical terms, I'm kinda new to this :) -- I hope it is understandable nevertheless.
Added as proposal 204: Thanks!
Title: Subdomain support for Hidden Service addresses Author: Alessandro Preite Martinez Created: 06-07-2012
1. Overview
This proposal aims to extend the .onion naming scheme for Hidden Service addresses with sub-domain components, which will be ignored by the Tor layer but will appear in HTTP Host headers, allowing subdomain-based virtual hosting.
2. Motivation
Sites doing large-scale HTTP virtual hosting on subdomains currently do not have a good option for exposure via Hidden Services, short of creating a separate HS for every subdomain (which in some cases is simply not possible due to the subdomains not being fully known beforehand).
3. Implementation
Tor should ignore any subdomain components besides the Hidden Service key, i.e. "foo.aaaaaaaaaaaaaaaa.onion" should be treated simply as "aaaaaaaaaaaaaaaa.onion".
The only part I'm worried about here is that we had once considered doing authenticated hidden services or some other kind of wacky hidden service with a design like "bbbbbbbbb.aaaaaaaaaaaaaaa.onion", where bbbbbbbbb is some additional data to use in the protocol. Still, we can still do the above proposal and save room to extend the .onion address scheme: just reserve *.x.onion for all x of length other than 16. -- Nick
On 7/7/12 7:06 PM, Nick Mathewson wrote:
The only part I'm worried about here is that we had once considered doing authenticated hidden services or some other kind of wacky hidden service with a design like "bbbbbbbbb.aaaaaaaaaaaaaaa.onion", where bbbbbbbbb is some additional data to use in the protocol.
Still, we can still do the above proposal and save room to extend the .onion address scheme: just reserve *.x.onion for all x of length other than 16.
From proposal 121, written in December 2007:
"Currently, rend-spec contains the proposition to encode client-side authorization data in the URL, like in x.y.z.onion. This was never used and is also a bad idea, because in case of HTTP the requested URL may be contained in the Host and Referer fields." Current rend-spec.txt doesn't mention anything like *.*.onion anymore. The way how additional data is provided is by using torrc options, not as part of the URL. Best, Karsten
On Tue, Jul 10, 2012 at 7:24 AM, Karsten Loesing <karsten@torproject.org> wrote:
On 7/7/12 7:06 PM, Nick Mathewson wrote:
The only part I'm worried about here is that we had once considered doing authenticated hidden services or some other kind of wacky hidden service with a design like "bbbbbbbbb.aaaaaaaaaaaaaaa.onion", where bbbbbbbbb is some additional data to use in the protocol.
Still, we can still do the above proposal and save room to extend the .onion address scheme: just reserve *.x.onion for all x of length other than 16.
From proposal 121, written in December 2007:
"Currently, rend-spec contains the proposition to encode client-side authorization data in the URL, like in x.y.z.onion. This was never used and is also a bad idea, because in case of HTTP the requested URL may be contained in the Host and Referer fields."
Current rend-spec.txt doesn't mention anything like *.*.onion anymore. The way how additional data is provided is by using torrc options, not as part of the URL.
Then I see no reason not to accept this proposal. Does anyone else? -- Nick
On Wed, Jul 11, 2012 at 11:09 AM, Nick Mathewson <nickm@alum.mit.edu> wrote:
Then I see no reason not to accept this proposal. Does anyone else?
Actually, there's a detail to think about: Isolation. If I connect to foo.aaaaa.onion bar.aaaaa.onion, should those streams be allowed to go over the same circuit? Right now I think they should not. yrs, -- Nick
participants (2)
-
Karsten Loesing -
Nick Mathewson