[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #16790 [Tor]: Tor should reload keys from disk when receiving a SIGHUP

#16790: Tor should reload keys from disk when receiving a SIGHUP
-------------------------+-------------------------------------------------
     Reporter:  s7r      |      Owner:  nickm
         Type:  defect   |     Status:  needs_revision
     Priority:  normal   |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor      |    Version:  Tor: 0.2.7.2-alpha
   Resolution:           |   Keywords:  ed25519, identity, keys,
Actual Points:           |  TorCoreTeam201509, PostFreeze027
       Points:           |  Parent ID:
-------------------------+-------------------------------------------------

Comment (by s7r):

 A proper behavior would be for Tor to do at every SIGHUP the same thing it
 does when starting, related to ed25519 router identity.

 That is why it is a little bit tricky to implement - we want to keep the
 'reload'/SIGHUP function which is sent very often (log rotation) without
 turning it into a 'restart' where uptime counter is reset, etc.

 I don't think it should try to reload the medium term signing key, don't
 think it can tell if this one is expired. Isn't the cert the one which
 states for how long the medium term signing key is valid?

 Here is a crazy idea.
 Remove the code in `ed25519_hup` / `ed25519_hup_v2` which tries to reload
 keys from disk when receiving a SIGHUP and do something like:

 When Tor runs as a relay, do a sha256sum of ed25519_signing_cert and
 ed25519_signing_secret_key and then another sha256sum of the 2 sums
 (cert|key - this order), so we have one value (one line). Add it to
 'state' file under some name.

 Whenever we receive a SIGHUP, calculate again the sha256sum of
 ed25519_signing_cert and ed25519_signing_secret_key and then another
 sha256sum of the 2 sums (cert|key - this order), and check the result
 against what we have in our state file. If different, turn the 'reload'
 into a 'restart', where we cover all the cases related to ed25519 identity
 keys.

 This means uptime counter reset, etc. but if the user changes the medium
 term signing key and certificate this is expected and wanted action anyway
 and even if it's not desired, can we call routerkeys function on the fly
 without losing uptime? If we can, let's call it on the fly. I want it to
 cover all the cases from fresh start at every SIGHUP because an operator
 can make same mistakes here, it's no different.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16790#comment:12>
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