Opened 5 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 5 years ago by asn

comment:2 Changed 5 years ago by asn

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 5 years ago by asn

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 5 years ago by nickm

Milestone: Tor: unspecified

comment:5 Changed 5 years ago by yawning

Keywords: tor-hs needs-proposal added

comment:6 Changed 5 years ago by 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?

comment:7 in reply to:  6 Changed 5 years ago by nickm

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 Changed 5 years ago by mo

Somewhat-duplicate of #2555? I like the proposed name "(Tor) encrypted services".

comment:9 Changed 5 years ago by naif

@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 in reply to:  8 Changed 4 years ago by asn

Resolution: duplicate
Status: newclosed

Replying to mo:

Somewhat-duplicate of #2555? I like the proposed name "(Tor) encrypted services".

ACK. Going to close this as dup of #2555.

Let's move there.

Note: See TracTickets for help on using tickets.