[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  teor
     Type:  enhancement                          |         Status:
 Priority:  Medium                               |  needs_information
Component:  Core Tor/Tor                         |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.???
 Keywords:  rsos, sos, tor2web, tor-hs,          |        Version:
  029-proposed, 029-nickm-unsure, 029-teor-no,   |     Resolution:
  needs-design, needs-proposal-maybe             |  Actual Points:
Parent ID:                                       |         Points:  5
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by teor):

 * status:  assigned => needs_information
 * keywords:
     rsos, sos, tor2web, tor-hs, 029-proposed, 029-nickm-unsure, 029-teor-
     yes, TorCoreTeam201607
     =>
     rsos, sos, tor2web, tor-hs, 029-proposed, 029-nickm-unsure, 029-teor-
     no, needs-design, needs-proposal-maybe
 * points:  2 => 5


Comment:

 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?
   * 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?
   * are arbitrary intro points a significant issue for a non-anonymous
 client?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17945#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs