Opened 20 months ago

Closed 8 months ago

Last modified 8 months ago

#21295 closed enhancement (wontfix)

Allow mixed anonymous and non-anonymous onion services in the same tor instance

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, single-onion, prop224, maybe-bad-idea
Cc: Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor:

Description

Similar to #21284, some single onion service users want to be able to use hidden (double onion) services most of the time, and single onion services occasionally with trusted peers.

For example, see the OnionShare use case in:
https://lists.torproject.org/pipermail/tor-dev/2017-January/011782.html

One potential anonymity issue is that any introduction and rendezvous points see the single onion service's IP addresses, as does anyone with access to the networks those relays are on.

But anyone with access to the network the single onion service is on also sees its IP address, and that it is creating tor traffic. So I'm not sure how much of a threat this is.

Child Tickets

Change History (11)

comment:1 Changed 20 months ago by teor

One workaround is to start another tor instance for the single onion service(s).

comment:2 Changed 15 months ago by cypherpunks

Keywords: prop224 rsos added

This is prop224 work, no?

comment:3 Changed 15 months ago by cypherpunks

Keywords: sos added; rsos removed

Oops, sos and not rsos

comment:4 Changed 15 months ago by teor

Keywords: sos removed

Now there's only one kind of single onion service, remove all references to old sos tag

comment:5 Changed 15 months ago by nickm

Keywords: maybe-bad-idea added

comment:6 Changed 13 months ago by cypherpunks

Milestone: Tor: unspecifiedTor: 0.3.2.x-final

comment:7 Changed 13 months ago by dgoulet

Milestone: Tor: 0.3.2.x-finalTor: unspecified

For the 032 release, prop224 will *not* allow mixed service. I'm still skeptical of this for the record.

comment:8 Changed 8 months ago by cypherpunks

Please cc micahlee for this since he's the maintainer of OnionShare.

comment:9 Changed 8 months ago by teor

Resolution: wontfix
Status: newclosed

I just don't think this is safe, particularly as part of Tor's current design.

We are adding vanguards to make onion services harder to discover.
And we want to reject connections to HSDir, intro, and rendezvous points where there is a client directly connected on both sides.

If someone does want to give up their anonymity, they should run another tor instance, or restart their current instance in non-anonymous mode.

Or we should develop a feature where controllers can set custom onion service paths.

comment:10 in reply to:  9 ; Changed 8 months ago by cypherpunks

Replying to teor:

If someone does want to give up their anonymity, they should run another tor instance, or restart their current instance in non-anonymous mode.

Or we should develop a feature where controllers can set custom onion service paths.

Please cc micahlee so that he can know that. :)

comment:11 in reply to:  10 Changed 8 months ago by teor

Replying to cypherpunks:

Replying to teor:

If someone does want to give up their anonymity, they should run another tor instance, or restart their current instance in non-anonymous mode.

Or we should develop a feature where controllers can set custom onion service paths.

Please cc micahlee so that he can know that. :)

Some people don't like being cc'd to lots of tickets. Micah had the opportunity to cc himself when I sent the original list email, and chose not to.

A more appropriate action is to respond to the original list thread:
https://lists.torproject.org/pipermail/tor-dev/2018-January/012862.html

Note: See TracTickets for help on using tickets.