Opened 7 years ago

Last modified 3 years ago

#9685 reopened enhancement

Improve Tor2web mode performance by having Tor2web client to be the RendezVous Point

Reported by: naif Owned by:
Priority: Very Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs tor2web performance
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Improve Tor2web mode performance by having Tor2web client to be the RendezVous Point of the connection to the Tor Hidden Service.

Child Tickets

Change History (5)

comment:1 Changed 7 years ago by nickm

Component: - Select a componentTor
Keywords: tor2web added
Milestone: Tor: unspecified

Cool idea.

This should probably be an option, since not everybody would necessarily want to run with an open (possibly unpublished) ORPort, which is necessary in order to be an RP.

comment:2 Changed 6 years ago by nickm

Resolution: duplicate
Status: newclosed

Closing as duplicate of #12844 , since that one has a patch.

comment:3 Changed 6 years ago by asn

Resolution: duplicate
Status: closedreopened

Reopening this after suggestion by arma in comment:26:ticket:12844 .

He said that Tor2webRendezvousPoints could theoretically point to a host with an ORPort open but without it necessarily being a public relay. This could be a good thing, because if we want tor2web to use this optimization, it doesn't necessarily mean that we also have to setup a relay (that drains bandwidth)

comment:4 Changed 5 years ago by teor

This setup may already be available via the config option:
ORPort 9123 NoAdvertise
And perhaps also:
PublishServerDescriptor 0

This will open the listed ORPort on all interfaces, but won't add it to the consensus.

Open issues:

  • I'm pretty sure clients and middle relays will accept a RP that isn't in the consensus, but we should test this. (If RefuseUnknownExits is set to 1 in the consensus, most relays will refuse to exit using a relay that not in the consensus. We should check that this doesn't block RPs.)
  • I don't think there's currently any way to prevent arbitrary clients/relays connecting to the ORPort and relaying non-RP traffic through the host to the rest of the Tor network, apart from excluding it from the consensus, therefore making it hard to discover. We could add an option which leaves the ORPort open to terminate RP connections, but disables (most/other) relaying (like ClientOnly).

Is there any other issues which I've missed?

comment:5 Changed 3 years ago by nickm

Keywords: performance added
Priority: MediumVery Low
Severity: Normal
Note: See TracTickets for help on using tickets.