Opened 4 years ago
Closed 4 years ago
#15271 closed enhancement (duplicate)
Enable exposing a Tor HS without Location Anonymity (-3 hops)
Reported by: | naif | Owned by: | |
---|---|---|---|
Priority: | Medium | Milestone: | Tor: unspecified |
Component: | Core Tor/Tor | Version: | |
Severity: | Keywords: | tor-hs, needs-proposal | |
Cc: | asn, virgil, yawning | Actual Points: | |
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
There are certain scenario where a Tor Hidden Service does not need Location Anonymity, think for example to the Facebook use-case.
In a very similar way to the Tor2web mode for outgoing connection to Tor Hidden Service, this ticket is to enable a Tor Hidden Service to remove it's 3-hops by connecting directly to it's RendezVous Point.
It's desiderable that this feature should work also with #12844 allowing a Tor Hidden Service to become a RendezVous point itself.
It's suggest that this feature become part of Tor2web mode of Tor, so that when Tor2web mode is enabled there's:
- -3 Hops on outgoing connection (when connecting to a Tor HS)
- -3 Hops on incoming connections (when exposing a Tor HS)
This feature would be required for Facebook and for OnionFlare feature of Tor2web described at https://github.com/globaleaks/Tor2web/issues/228 .
Child Tickets
Change History (10)
comment:1 Changed 4 years ago by
comment:2 Changed 4 years ago by
I wonder if we should also cut circuits to IPs and circuits to HSDirs down to 1-hop with this feature?
My intuition tells me we should, since we are going for the fastest thing possible and we don't care about anonymity. Roger's proposal seems to suggest the opposite:
One design question to ponder: should we continue to use three-hop circuits for our introduction points, and for publishing our encrypted service descriptor? Probably.
Also here is a tor-dev thread about how this feature should be named:
https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html
Current suggestions are direct service or Tor-required service. I think more suggestions would be useful.
comment:3 Changed 4 years ago by
Also, no reason for such hidden services to use a single guard node, right? Might as well spread the damage out to multiple guard nodes.
comment:4 Changed 4 years ago by
Milestone: | → Tor: unspecified |
---|
comment:5 Changed 4 years ago by
Keywords: | tor-hs needs-proposal added |
---|
comment:6 follow-up: 7 Changed 4 years ago by
If you compile tor with Tor2web mode you already get a 1-hop circuit to a rendezvous point when exposing a HS.
Is there something that Tor2web mode does not provide that you would like to have?
comment:7 Changed 4 years ago by
Replying to hellais:
If you compile tor with Tor2web mode you already get a 1-hop circuit to a rendezvous point when exposing a HS.
Is there something that Tor2web mode does not provide that you would like to have?
If I understand correctly:
This would be the converse of Tor2web: instead of providing a way to non-anonymously access a hidden service, this ticket is about providing a way to non-anonymously host a "hidden" service.
comment:8 follow-up: 10 Changed 4 years ago by
Somewhat-duplicate of #2555? I like the proposed name "(Tor) encrypted services".
comment:9 Changed 4 years ago by
@mo I can argue that if this feature is part of Tor2web mode, then it can be considered experimental, confined, contained functionalities that are not exposed to any general user (so, are not part of standard Tor, maybe to #15199 if someone will pick it up), with less constraint than standard Tor?
@hellais are you 100% sure that in Tor2web mode the Tor HS hosting goes 1-hops? Alec from Fbook said they had to do some experimental code patching (likely to be shared on this ticket)
comment:10 Changed 4 years ago by
Resolution: | → duplicate |
---|---|
Status: | new → closed |
And here is Roger's quasi-proposal on similar concepts:
https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted-services.txt