Stop single hop client connections to Single Onion Services
Tor2Web clients make a one-hop connection to HSDirs, intro points, and rend points. Single Onion Services also make a one-hop connection to the rendezvous point.
This uses Tor as a one-hop proxy (in this case, to a single onion service), which we try to avoid, because it enables certain attacks. We also try to avoid single hop connections in the onion service protocol, because they give IP addresses to middle relays.
See the child tickets for details.
Activity
changed milestone to %Tor: unspecified
added 029-proposed 029-teor-no 034-removed-20180328 034-triage-20180328 actualpoints::0.4 component::core tor/tor milestone::Tor: unspecified needs-design needs-proposal-maybe parent::24962 points::5 priority::medium resolution::duplicate review-group-33 severity::normal single-onion status::closed tor-hs tor2web type::enhancement labels
Replying to teor:
Tor2Web clients make a one-hop connection to the rendezvous point. Rendezvous Single Onion Services also make a one-hop connection to the rendezvous point. (Single Onion Services expect a client to make an extend request to the Single Onion Service at the end of a 3-hop path.) ... For Rendezvous Single Onion Services, I don't know how to prevent this happening. (Should the rendezvous point intervene? Should we add something to the RSOS descriptor?)
The rendezvous point (and possibly the introduction point) could terminate the connection if it has a single hop on both ends. This seems to be the most correct option.
RSOS descriptors could claim to be a RSOS, and then Tor2web can avoid connecting to the RSOS. But this provides a generic method for hidden services to block Tor2web. I'm not sure we want that, and I don't know if all Tor2web operators would enable the feature.
Trac:
Keywords: N/A deleted, tor2web addedIn #18082 (moved), we may have Rendezvous Single Onion Services add an identifying line to their descriptors,so we could measure their HSDir statistics separately.
If we identify RSOS in their descriptor, then we can make sure Tor2web clients don't connect to them (#17945 (moved)).
I'll look at this again in 0.2.9.
Trac:
Parent: #17178 (moved) to N/AThis can be done by blocking the X-Tor2web header, as detailed here: https://lists.torproject.org/pipermail/tor-onions/2016-February/000050.html
This was raised on the tor-project mailing list, and I said:
We'e yet to arrive at a mechanism to make this happen, but I think we will end up adding a line to the onion service descriptor. We could make this a configuration parameter (AllowTor2Web?) that defaults to 1 for hidden services, and 0 for single onion services.
https://lists.torproject.org/pipermail/tor-project/2016-May/000333.html
Replying to teor:
Replying to teor:
Tor2Web clients make a one-hop connection to the rendezvous point. Rendezvous Single Onion Services also make a one-hop connection to the rendezvous point. (Single Onion Services expect a client to make an extend request to the Single Onion Service at the end of a 3-hop path.) The rendezvous point (and possibly the introduction point) could terminate the connection if it has a single hop on both ends. This seems to be the most correct option.
This could result in false positives if the consensus gets out of sync. Or is there a reliable way for a relay to detect non-relays without using the consensus? (How does the padding do it?)
Replying to teor:
Replying to teor:
Replying to teor:
Tor2Web clients make a one-hop connection to the rendezvous point. Rendezvous Single Onion Services also make a one-hop connection to the rendezvous point. (Single Onion Services expect a client to make an extend request to the Single Onion Service at the end of a 3-hop path.) The rendezvous point (and possibly the introduction point) could terminate the connection if it has a single hop on both ends. This seems to be the most correct option.
This could result in false positives if the consensus gets out of sync. Or is there a reliable way for a relay to detect non-relays without using the consensus? (How does the padding do it?)
arma says on tor-project@ that we can do it the same way exits do it - by aggressively fetching the consensus from the authorities. (Fortunately, fallback directories in 0.2.8 will reduce the client load on authorities, allowing relays scope to do this.)
Then we can teach single onion services to advertise their single-hop nature in their descriptors, and tor2web and similar clients to build multi-hop paths to intro and rendezvous points for those services.
Then we can teach single onion services to advertise their single-hop nature in their descriptors, and tor2web and similar clients to build multi-hop paths to intro and rendezvous points for those services.
Totally support this solution. If clients can detect which domains are single-onion services then tor2web-mode can be made to simply add an another hop for those domains. Seems solid to me.
Replying to cypherpunks:
What would be best is a way to keep tor2web mode clients from connecting to one's HS at all.
Some tor2web clients set the
x-tor2web: trueHTTP header.This isn't a protool-agnostic solution by any means, and it still involves exchanging some data with those clients. https://lists.torproject.org/pipermail/tor-project/2016-May/000362.html
Then we can teach single onion services to advertise their single-hop nature in their descriptors, and tor2web and similar clients to build multi-hop paths to intro and rendezvous points for those services.
Following up on the above---minimizing the RP's juiciness to attack is definitely a good idea. This solution above is the best solution I've heard.
There are three different but related issues here. We have a design that fixes them, but there are some drawbacks. So this needs some more design work, and perhaps a proposal.
Stop Tor2web connecting to Single Onion Services:
Relays should avoid being the only relay in a circuit between Tor2web and a Single Onion Service - so it isn't in a position to de-anonymise both client and service (this discourages attacks)
- intro points and rend points should require one or both sides of the connection to be in the consensus
- this has load-balancing issues, as the way exits check for relays is to fetch consensuses from the authorities
- do we want all relays to have to fetch from authorities? Maybe 7000 relays is not a big issue
- maybe we could use the solution that netflow padding uses?
- this has load-balancing issues, as the way exits check for relays is to fetch consensuses from the authorities
- teach Tor2web to build a 3?-hop path to a single onion service to avoid being blocked by this feature
- this may have compatibility issues with older versions, because we need to mark single onion service descriptors as coming from a single onion service, so Tor2web knows to build a longer path, but older clients / HSDirs might not be able to parse descriptors with extra fields
Stop clients sending arbitrary Rendezvous points to Single Onion Services:
- teach single onion services to check that the rendezvous point is in the consensus
- what if we want to allow this as a feature? (have a per-service "unsafe" option?)
- this has load-balancing issues, as the way exits check for relays is to fetch consensuses from the authorities
- do we want all single onion services to have to fetch from authorities? If they become popular, this could create a huge load on the authorities (what if someone launches 1000 single onion service instances?)
- maybe we could use the solution that netflow padding uses?
- are arbitrary rendezvous points a significant issue for a non-anonymous service?
Stop hidden services sending arbitrary Intro points to Tor2web:
- teach Tor2web to check that the intro point is in the consensus
- this has load-balancing issues, as the way exits do this is to fetch consensuses from the authorities
- do we want all Tor2web clients to have to fetch from authorities? Is Tor2web that popular already? This could inadvertently create a huge load on the authorities
- maybe we could use the solution that netflow padding uses?
- this has load-balancing issues, as the way exits do this is to fetch consensuses from the authorities
- are arbitrary intro points a significant issue for a non-anonymous client?
Trac:
Points: 2 to 5
Keywords: TorCoreTeam201607, 029-teor-yes deleted, 029-teor-no, needs-design, needs-proposal-maybe added
Status: assigned to needs_information- intro points and rend points should require one or both sides of the connection to be in the consensus
