[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #6419 [Tor]: is it really a protocolwarn when connection_or_client_learned_peer_id() finds a different keyid?
#6419: is it really a protocolwarn when connection_or_client_learned_peer_id()
finds a different keyid?
--------------------------------------+-------------------------------------
Reporter: arma | Owner:
Type: defect | Status: new
Priority: minor | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version:
Keywords: tor-relay 024-deferrable | Parent:
Points: | Actualpoints:
--------------------------------------+-------------------------------------
Comment(by andrea):
{{{
19:10 < nickm> #6419 is next
19:11 < nickm> The fix is just "change a log severity." First we need to
decide whether to change the log severity.
Sounds like less than 30 minutes of work total.
19:11 * athena looks at #6419
19:11 < nickm> (Assuming I'm reading armadev right, which I might not be)
19:11 < asn> change log severity when dirauth, maybe.
19:13 < asn> change log severity when dirauth and reachability testing,
maybe?
19:13 < asn> hm.
19:13 < nickm> asn: If you can determine the right answer and write a
patch, the work is done here. :)
19:14 < asn> ha! nasty nickm!
19:14 < athena> yeah, i say keep and downgrade
19:14 < athena> i do that all the time when i run test relays
19:14 < nickm> to minor? ok
19:14 < nickm> oh, or downgrade the warning?
19:14 < athena> so it shouldn't be warning
19:15 < athena> yeah, the proposed solution in the ticket sounds correct
to me
19:15 < asn> are there cases where a dirauth would like to see this
warning?
19:15 < athena> but it also sounds easy enough that it arguably should be
minor
19:15 < asn> shouldn't it warn when it builds circuits to do non-
reachability-testing things?
19:16 < asn> (what other things do dirauths do and need to build circuits
for?)
19:16 < nickm> Actually hm.
19:16 < nickm> You want to get warned about this in some cases but not
others maybe?
19:16 < asn> mmaybe the clause should be (if dirauth &&
reachability_testing) LOG_NOTICE, otherwise LOG_WARN. Although
that might bring it to the <more than 30 minutes of work>
area.
19:17 < nickm> My thought was that: if you are extending to 1.2.3.4:1111
with ID ABCDEFABCDEFABCDEF12 and it gives you
some other ID, you don't care: the problem could be on the
client's end; they could ahve told you a bad
key
19:17 < nickm> if you got the key out of a consensus directory yourself...
19:17 < nickm> ...or because a router uploaded it to you...
19:17 < nickm> maybe you care more?
19:17 < nickm> If that's the case, this is harder.
19:19 < athena> so, dirauths should warn because ... they should always
get told about new routers so they should
always know the latest identity digest for a given IPv4
address?
19:19 < athena> is that necessarily true
19:19 < athena> ?
19:19 < nickm> I don't know
19:19 < nickm> I mean, I can make up a new identity key for your router
and send it to all the DAs and they'll be like "oh reeeeeeeally?"
19:20 < athena> for example, suppose i set up a new router on an ip that
just recently had a different key
19:20 < athena> and then, being tricksy for the sake of it, i mess with
iptables so outgoing TCP connections from that
router to one particular dirauth are blocked
19:20 < athena> but incoming ones from the dirauth to the router are
permitted
19:20 < nickm> I've commented, downgraded to minor, and added
024-deferrable. It should be easy once we decide what we
meant here, but it seems like we could skip it
19:20 < athena> then surely it's possible for the dirauth to see a
different key than it expects
}}}
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6419#comment:7>
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