#19163: Maybe RSOS single-hop circuits should always have ntor ---------------------------------------------+----------------------------- Reporter: teor | Owner: teor Type: defect | Status: Priority: Medium | needs_revision Component: Core Tor/Tor | Milestone: Tor: Severity: Normal | 0.2.9.x-final Keywords: rsos, tor-hs, TorCoreTeam201607 | Version: Parent ID: | Resolution: Reviewer: | Actual Points: 3 | Points: 1.0 | Sponsor: ---------------------------------------------+----------------------------- Changes (by teor):
* status: new => needs_revision * actualpoints: => 3 Comment: Please see my branch reject-tap on https://github.com/teor2345/tor.git It makes the following changes: authorities: * should reject all descriptors that include only a TAP key (unless they do already) * dirserv_get_status_impl already rejects versions older than 0.2.4.18-rc, and ntor was introduced in 0.2.4.8-alpha. So there should be no TAP-only routers in the consensus. * But we don't actually check if each descriptor has an ntor key in dirserv_router_get_status. 2171a79 rejects descriptors where onion_curve25519_pkey is NULL. This comes before the version check. So the message for very old relays will change. 817ee49 is a fixup which also rejects descriptors where the ntor key is all zero (this is the actual check the client performs, so we should replicate it on the authorities) relays: * bridges must support ntor * guards / directory guards must support ntor 329ff78 relays make sure their own descriptor has an ntor key clients (and client code): descriptor downloads: 6cc2d2c Clients no longer download descriptors for relays without ntor relay selection: * we should only select guards with ntor * we should only select directory guards with ntor * we should only select directories with ntor * we should only select exits with ntor * hidden service clients should choose rendezvous points that have ntor * hidden services should choose introduction points that have ntor e3a0b50 Clients avoid choosing nodes that can't do ntor Nodes that have a version that's too old, or a descriptor without an ntor key, are not considered running. (Nodes without versions or descriptors are permitted.) path selection: * never select a TAP-only router in any hop in any circuit c341848 Make sure every hop in every path supports ntor We check when selecting nodes for the path, and when creating extend_infos for the path. We can't check in extend_info_new, because some extend_infos legitimately don't know the ntor key. d83b655 Make sure every relay in a path supports ntor, not just one Change the definition of "path supports ntor" to "all relays support ntor" (it was "at least one relay supports ntor") circuit building: * make sure every extend actually uses ntor, to protect against downgrade attacks * stop and warn if we connect to a bridge that doesn't support ntor * this happens automatically as part of circuit-building * note that some single-hop connections (such as bootstrap connections) still use CREATE_FAST * hidden services can use ntor if the intro/rend points are in the consensus 44e1d19 Deprecate UseNTorHandshake, assume all hops use ntor 0ceb4b2 Clients require hidden service intro points to have an ntor key 1630e1d Hidden services require rend points to have an ntor key This code is in my branch reject-tap-v2 on https://github.com/teor2345/tor.git, but it needs revision. Currently, if intro or rend points aren't in the consensus the client or hidden service has, they can't be used (because there is no ntor onion key available for them). Therefore: * intro and rend points should check if they are missing either the ntor or the TAP key, and if either are missing, look up both in the consensus * intro and rend points that aren't in the consensus should be available via TAP -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19163#comment:6> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs