[tor-bugs] #19163 [Core Tor/Tor]: Maybe RSOS single-hop circuits should always have ntor

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Jul 8 06:54:55 UTC 2016


#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


More information about the tor-bugs mailing list