Opened 2 years ago

Last modified 21 months ago

#21285 new enhancement

Add tor compilation to disable all non-anonymous services

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

Description

Some users have requested an option to disable single onion services entirely.

This should disable single onion services, the non-anonymous SocksPort out of #21284, and should conflict with --enable-tor2web-mode.

Child Tickets

Change History (6)

comment:1 Changed 2 years ago by dgoulet

My two cents. This is something I'm not too excited about and I've expressed my opinion here on this thread: https://lists.torproject.org/pipermail/tor-talk/2016-December/042794.html

IMHO, that won't make user safer in the way that they think it might. Removing at compile time code that enables that feature is not going to achieve that. Tor will still have capabilities for 1-hop circuit... Tor will still have a function in the code asking "am I a single onion" which compiled in code or not could have a bug...

Having such an option would create more unstable code because it will get less tested overtime because it's a compiled in option not living with our evolving code base.

Last edited 2 years ago by dgoulet (previous) (diff)

comment:2 Changed 2 years ago by s7r

I think this is not worth the effort because it will not achieve additional security in any way. The 1-hop circuit capability will remain in Tor, just that you won't be able to create single hop onion services which you would anyway need to add not one but two torrc options in order to make it work, torrc options that are long and explicit and most probably acknowledged from a manual or tutorial among with other clear explanations.

It's important to highlight that 1 hop circuits are not something new to Tor introduced with the single onion services feature, and might be used accidentally or buggy with regular onion services. They always existed and will continue to do so even with this option.

comment:3 in reply to:  2 ; Changed 2 years ago by teor

Replying to s7r:

I think this is not worth the effort because it will not achieve additional security in any way. The 1-hop circuit capability will remain in Tor, just that you won't be able to create single hop onion services which you would anyway need to add not one but two torrc options in order to make it work, torrc options that are long and explicit and most probably acknowledged from a manual or tutorial among with other clear explanations.

It's important to highlight that 1 hop circuits are not something new to Tor introduced with the single onion services feature, and might be used accidentally or buggy with regular onion services. They always existed and will continue to do so even with this option.

Single-hop circuits have existed for directory fetches and Tor2Web for quite some time.

comment:4 in reply to:  3 Changed 2 years ago by s7r

Replying to teor:

Single-hop circuits have existed for directory fetches and Tor2Web for quite some time.

Exactly - as I said, always existed and will continue to exist even if a compilation option is added to disable the RSOS code, so it will not offer any real gain for someone using it, while the downside of creating some unstable less tested code remains real.

comment:5 Changed 2 years ago by yawning

I was the one that asked for this, and I don't feel that strongly about it. If I care enough I'll just patch my local tor each release to revert the addition of the feature.

Single-hop circuits have existed for directory fetches and Tor2Web for quite some time.

Tor2Web is something that explicitly needs to be enabled at compile time for a very good reason. I happen to think that this should be treated in the same manner, but like I said on IRC, that ship has sailed, and the point at which I should be arguing about this was prior to it being merged.

comment:6 Changed 21 months ago by nickm

Keywords: maybe-bad-idea build modularity added
Note: See TracTickets for help on using tickets.