[tor-bugs] #6419 [Tor]: is it really a protocolwarn when connection_or_client_learned_peer_id() finds a different keyid?

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Mar 14 02:23:20 UTC 2013


#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


More information about the tor-bugs mailing list