Alternate Single Onion Service Designs
Hi all, Do we need both single onion services (Proposal 252) and rendezvous single onion services? We want to enable secure usage by default, and avoid splitting anonymity sets. But we also want to support real-world use cases, because anonymous protocols are safer if more people use them. There are currently two different proposed single onion service designs: * Single Onion Services (SOS - Proposal 252): require an ORPort, no introduction/rendezvous, one-hop extend * Rendezvous Single Onion Services (RSOS - No Proposal Number): introduction/rendezvous with one-hop paths I see at least the following scenarios for using these alternate single onion service designs: 0. an onion service operator who wants to minimise latency and maximise bandwidth runs a SOS (a RSOS is slower to connect due to the rendezvous protocol) 1. an onion service operator runs a SOS for new clients, and an RSOS for old clients (a RSOS is compatible with current clients, a SOS Is not) 2. an onion service operator who can’t expose an ORPort runs a RSOS for all clients (there are enclave and NAT configurations where external ports are an issue) 3. an onion service operator who wants to use Proposal 255 for load-balancing runs a RSOS, and splits their introduction and rendezvous instances by passing the introduction over the control port (proposal 255 relies on the rendezvous protocol to handoff the rendezvous point connection to another Tor instance) 4. an onion service wants low latency and better bandwidth, and doesn't want to wait until the SOS feature is developed and deployed (SOS is a larger feature, and it needs client changes). They'll switch to SOS when it's well supported by installed versions of Tor Browser. Given these use cases, I think we could implement both flavours of single onion service. But this splits the onion service anonymity set at least 3 ways (and maybe also by some other onion service features). I'm not sure how much of an impact this will have - it does depend on our threat model for each flavour of onion service. If we wanted to generate more onion service cover traffic, we could move various automated Tor Browser actions (such as update checks and update downloads) to appropriate flavours of onion service. This would shift load away from exits, and also have address authentication benefits. (Tor Browser wouldn't have to rely on DNS, CA certificates, and SSL for Its updates.) The other mitigations I'm aware of are cover traffic and lookalike protocol interactions, but these require significant research and design work. We're working on implementing rendezvous single onion services in #17178. I think they're pretty close: we need to do some more testing, and handle some edge cases. RSOS servers work with existing clients, including current Tor Browser releases. Single onion services (Proposal 252) is a larger feature, so it's a bit further away. SOS are incompatible with current clients, so supporting code will need to be deployed in Tor clients (such as Tor Browser) as well as on the onion service itself. After the feature is ready, there will be some lead time before SOS are usable with the majority of deployed Tor clients. What do you think? Are onion services big enough to safely have multiple flavours? Could they get that big if we support enough functionality? Or are we better to implement secure, one-size-fits-all defaults, and ask users and operators to sacrifice some performance? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On Nov 6, 2015, at 4:56 PM, teor <teor2345@gmail.com> wrote: Do we need both single onion services (Proposal 252) and rendezvous single onion services?
I would say they are both desirable, and that we could/should have both. RSOS is great for adoption, the rendezvous step enables NAT-punching and yet lowers latency. The NAT-punching is particularly desirable where - like in our configuration - the tor daemon resides in a DMZ enclave without inbound connectivity. See diagram at: https://twitter.com/dcuthbert/status/573197027242315776/photo/1 Source: https://storify.com/AlecMuffett/tor-tips RSOS thereby also offers a easy, nearly-no-rearchitecture-required route to enterprise deployment. Also RSOS enables OnionBalance, and other performance hacks such as those proposed by Tom van der Woerdt (https://lists.torproject.org/pipermail/tor-dev/2015-October/009618.html) all without requiring broad changes to deployed Tor daemons SOS by comparison sounds best where pure performance matters, but I am not sure how the other scaling solutions will fit into it; but pure performance matters a lot, so overall I think I’d like to see both. My plans for Onion scaling are approximately as follows: 1) Remove unnecessary privacy hops / deploy RSOS (in progress) 2) OnionBalance: Merge introduction points (IPs) from multiple daemons into one descriptor (possible issue: there is a hardcoded limit of 3x IPs?) 3) Steven Murdoch / Ceysun Sucu research: Implement distinct OnionBalance descriptors at each (6?) point on the HSDir ring These three solutions in aggregate should lower latency and scale tor daemon bandwidth by a range of 18..60x Then: 4) (Wishlist) implementation of TVDW's handoff of RP callback ...which will resolve any remaining CPU-bandwidth issues. These plans are subject to change, but seem reasonable so far. - alec
I see at least the following scenarios for using these alternate single onion service designs:
0. an onion service operator who wants to minimise latency and maximise bandwidth runs a SOS (a RSOS is slower to connect due to the rendezvous protocol)
1. an onion service operator runs a SOS for new clients, and an RSOS for old clients (a RSOS is compatible with current clients, a SOS Is not)
2. an onion service operator who can’t expose an ORPort runs a RSOS for all clients (there are enclave and NAT configurations where external ports are an issue)
3. an onion service operator who wants to use Proposal 255 for load-balancing runs a RSOS, and splits their introduction and rendezvous instances by passing the introduction over the control port (proposal 255 relies on the rendezvous protocol to handoff the rendezvous point connection to another Tor instance)
4. an onion service wants low latency and better bandwidth, and doesn't want to wait until the SOS feature is developed and deployed (SOS is a larger feature, and it needs client changes). They'll switch to SOS when it's well supported by installed versions of Tor Browser.
Given these use cases, I think we could implement both flavours of single onion service. But this splits the onion service anonymity set at least 3 ways (and maybe also by some other onion service features). I'm not sure how much of an impact this will have - it does depend on our threat model for each flavour of onion service.
If we wanted to generate more onion service cover traffic, we could move various automated Tor Browser actions (such as update checks and update downloads) to appropriate flavours of onion service. This would shift load away from exits, and also have address authentication benefits. (Tor Browser wouldn't have to rely on DNS, CA certificates, and SSL for Its updates.)
The other mitigations I'm aware of are cover traffic and lookalike protocol interactions, but these require significant research and design work.
We're working on implementing rendezvous single onion services in #17178. I think they're pretty close: we need to do some more testing, and handle some edge cases. RSOS servers work with existing clients, including current Tor Browser releases.
Single onion services (Proposal 252) is a larger feature, so it's a bit further away. SOS are incompatible with current clients, so supporting code will need to be deployed in Tor clients (such as Tor Browser) as well as on the onion service itself. After the feature is ready, there will be some lead time before SOS are usable with the majority of deployed Tor clients.
What do you think? Are onion services big enough to safely have multiple flavours? Could they get that big if we support enough functionality? Or are we better to implement secure, one-size-fits-all defaults, and ask users and operators to sacrifice some performance?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.torproject.org_cg...
On 7 Nov 2015, at 04:36, Alec Muffett <alecm@fb.com> wrote:
These three solutions in aggregate should lower latency and scale tor daemon bandwidth by a range of 18..60x
Then:
4) (Wishlist) implementation of TVDW's handoff of RP callback
...which will resolve any remaining CPU-bandwidth issues.
These plans are subject to change, but seem reasonable so far.
Rendezvous handoff is partially implemented in: https://trac.torproject.org/projects/tor/ticket/17254 <https://trac.torproject.org/projects/tor/ticket/17254> I think we're waiting on the following: * a more detailed specification of the handoff data fields for current and next-generation onion services, so we can be sure it's future-proof (I believe this is the decrypted and parsed cell content) * confirmation that the introduction-side will decrypt (and parse) the INTRODUCE2 cell, to avoid sending introduction point private keys over the control port (this puts slightly more load on the introduction point, but a single message compromise would only compromise that rendezvous, not all the rendezvous for that day from that introduction point) Together, these two changes would also support the "rendezvous approver" control port feature, where the handoff controller can filter requests as needed based on their content or on external factors such as load. This also might be a nice way of doing geographical load-balancing: an introduction for a European rendezvous point could be sent to a nearby European data center to perform the actual rendezvous. Alternately, it could be send to a lightly-loaded instance. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On 6 Nov 2015, at 17:36, Alec Muffett <alecm@fb.com<mailto:alecm@fb.com>> wrote: My plans for Onion scaling are approximately as follows: 1) Remove unnecessary privacy hops / deploy RSOS (in progress) 2) OnionBalance: Merge introduction points (IPs) from multiple daemons into one descriptor (possible issue: there is a hardcoded limit of 3x IPs?) 3) Steven Murdoch / Ceysun Sucu research: Implement distinct OnionBalance descriptors at each (6?) point on the HSDir ring Ceysun now has a blog post summarising option 3 here: https://www.benthamsgaze.org/2015/11/17/scaling-tor-hidden-services/ Full details are in his thesis: https://www.benthamsgaze.org/wp-content/uploads/2015/11/sucu-torscaling.pdf Best wishes, Steven
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi teor, I like RSOS more and it removes 2 hops from a circuit which is quite A LOT. This is a significant step for operators that require latency. RSOS combined with OnionBalance or rendezvous approval feature which will allow scaling beyond what's needed in most cases. Also, RSOS is compatible with clients, the overall design is well studied and very much improved over time, provides free easy NAT punching (very useful) and doesn't bare all the requirements and attack surface of a SOS. I am happy having more and more services available via hidden services - - I think it wisely uses the surplus middle:exit ratio in the network, so having many options to offer to operators (RSOS, rendezvous approval, OnionBalance, SOS, etc.) is very good. On 11/6/2015 6:56 PM, teor wrote:
Hi all,
Do we need both single onion services (Proposal 252) and rendezvous single onion services? We want to enable secure usage by default, and avoid splitting anonymity sets. But we also want to support real-world use cases, because anonymous protocols are safer if more people use them.
There are currently two different proposed single onion service designs: * Single Onion Services (SOS - Proposal 252): require an ORPort, no introduction/rendezvous, one-hop extend * Rendezvous Single Onion Services (RSOS - No Proposal Number): introduction/rendezvous with one-hop paths
I see at least the following scenarios for using these alternate single onion service designs:
0. an onion service operator who wants to minimise latency and maximise bandwidth runs a SOS (a RSOS is slower to connect due to the rendezvous protocol)
1. an onion service operator runs a SOS for new clients, and an RSOS for old clients (a RSOS is compatible with current clients, a SOS Is not)
2. an onion service operator who can’t expose an ORPort runs a RSOS for all clients (there are enclave and NAT configurations where external ports are an issue)
3. an onion service operator who wants to use Proposal 255 for load-balancing runs a RSOS, and splits their introduction and rendezvous instances by passing the introduction over the control port (proposal 255 relies on the rendezvous protocol to handoff the rendezvous point connection to another Tor instance)
4. an onion service wants low latency and better bandwidth, and doesn't want to wait until the SOS feature is developed and deployed (SOS is a larger feature, and it needs client changes). They'll switch to SOS when it's well supported by installed versions of Tor Browser.
Given these use cases, I think we could implement both flavours of single onion service. But this splits the onion service anonymity set at least 3 ways (and maybe also by some other onion service features). I'm not sure how much of an impact this will have - it does depend on our threat model for each flavour of onion service.
If we wanted to generate more onion service cover traffic, we could move various automated Tor Browser actions (such as update checks and update downloads) to appropriate flavours of onion service. This would shift load away from exits, and also have address authentication benefits. (Tor Browser wouldn't have to rely on DNS, CA certificates, and SSL for Its updates.)
The other mitigations I'm aware of are cover traffic and lookalike protocol interactions, but these require significant research and design work.
We're working on implementing rendezvous single onion services in #17178. I think they're pretty close: we need to do some more testing, and handle some edge cases. RSOS servers work with existing clients, including current Tor Browser releases.
Single onion services (Proposal 252) is a larger feature, so it's a bit further away. SOS are incompatible with current clients, so supporting code will need to be deployed in Tor clients (such as Tor Browser) as well as on the onion service itself. After the feature is ready, there will be some lead time before SOS are usable with the majority of deployed Tor clients.
What do you think? Are onion services big enough to safely have multiple flavours? Could they get that big if we support enough functionality? Or are we better to implement secure, one-size-fits-all defaults, and ask users and operators to sacrifice some performance?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJWPkq1AAoJEIN/pSyBJlsRxysIAM6GMNli5/CIJfugs1dFJz8S 94r0ezJnid/DZhEWfP40ywVNb2iJZOYUma6JE0XPS8lOatsJCE6wkWvx9a2tLouM pIepDsAY0cONwklIEnASIywcaAB5a5lrklFCU3gHQ3WX+1w0UxHn1QhUZUdoZaxe SjE4u6HLG/Be3Ooqp33y/uFd4RkJcZguZBDhOUBtCGfSLWLb2QfnCGgqXmhxZ9n3 guO6R/dVn7Qu1XOLq6n+OpJhUc5BkUx+H+p+OXfvN0f3x2Q4aWVjRLZOz2/A3Wy5 Ob/jUcdyjL+Odi8vJsmb0Ix/Qas6tTazHTC8CdX7vtzhvX5OJKpsui4VKTXoTlA= =xSVM -----END PGP SIGNATURE-----
participants (5)
-
Alec Muffett -
Murdoch, Steven -
s7r -
teor -
Tim Wilson-Brown - teor