[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #19163 [Core Tor/Tor]: Maybe RSOS single-hop circuits should always have ntor
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs