Tor should reload keys from disk when receiving a SIGHUP
When running as a relay and receiving a HUP signal (reload) Tor should reload and validate keys from disk again. It would do the same validation operations related to ed25519 identity keys as when started normally.
This way, an operator can generate and move the new medium signing key and certificate to $datadirectory/keys and easily do a 'service tor reload'.
Change should be applied to ed25519_keygen branch. At this time, 0.2.7.2-alpha doesn't do the correct operations related to ed25519 identity keys at startup.
Activity
changed milestone to %Tor: 0.2.7.x-final
Just to make sure: the option is enforced only when Tor wants or needs to generate new signing key and certificate (like when the signing key and certificate it has loaded in memory are going to expire soon), and is ignored otherwise?
I have deleted ed25519_master_id_public_key and only left a valid certificate and signing key, and sent a HUP signal to Tor, it reloaded just fine but did not generate and write to disk ed25519_master_id_public_key from the certificate, as we normally do when we start.
This has no importance - the behavior is correct either way just want to make sure I am describing it correctly in the documentation.
Replying to s7r:
Just to make sure: the option is enforced only when Tor wants or needs to generate new signing key and certificate (like when the signing key and certificate it has loaded in memory are going to expire soon), and is ignored otherwise?
I have deleted ed25519_master_id_public_key and only left a valid certificate and signing key, and sent a HUP signal to Tor, it reloaded just fine but did not generate and write to disk ed25519_master_id_public_key from the certificate, as we normally do when we start.
This has no importance - the behavior is correct either way just want to make sure I am describing it correctly in the documentation.
Hmm. I'm not 100% sure I understand the question here. :/
I was interested if the reload keys from disk on SIGHUP operation happens only when the current loaded signing key and certificate are due to expire soon (and Tor will not try to reload keys from disk when receiving a SIGHUP if the ones it has in memory are valid for for a reasonable time in future).
I have tested the latest branch, after receiving notifications that the medium term signing key and certificate will expire soon and Tor should try to generate new ones, I have manually generated new valid signing key and certificate and moved them to $datadirectory/keys and sent a SIGHUP to Tor - no more notifications in logs.
This doesn't work as expected yet.
I have created cert and temporary signing key with a lifetime of 2 days (the minimum allowed). After 24 hours, I got the normal expected warning:
[notice] It looks like I should try to generate and sign a new medium-term signing key, because the one I have is going to expire soon. To do that, I'm going to have to try to load the permanent master identity keyThis means that Tor should be in the stage when it would reload keys from disk when receiving a SIGHUP. It does not, it receives the SIGHUP and reloads. I have even deleted all the ed25519* files in $datadirectory/keys and sent a SIGHUP. Tor still remembered the cert and signing key loaded initially, and only did this:
Aug 24 10:44:54.000 [warn] No key found in /root/torsrc/data/keys/ed25519_master_id_secret_key or /root/torsrc/data/keys/ed25519_master_id_public_key. Aug 24 10:44:54.000 [warn] Master public key was absent; inferring from public key in signing certificate and saving to disk.Only generated and saved to disk ed25519_master_id_public_key and continued to run with just with this file in $datadirectory/keys. Obviously if I stop it and start again, it will exit since it's missing signing key and cert, but sending SIGHUP doesn't do anything, it just reloads:
Aug 24 10:52:08.000 [notice] It looks like I should try to generate and sign a new medium-term signing key, because the one I have is going to expire soon. To do that, I'm going to have to try to load the permanent master identity key Aug 24 10:52:15.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. Aug 24 10:52:15.000 [notice] Read configuration file "/root/torsrc/torrc". Aug 24 10:52:39.000 [notice] It looks like I should try to generate and sign a new medium-term signing key, because the one I have is going to expire soon. To do that, I'm going to have to try to load the permanent master identity keyNot saving to disk the cert and medium term signing key already existent in memory on SIGHUP is not a bug, we actually do not want that behavior. What we want is just to call the ed25519 key validation protocol on a SIGHUP every time, the same as when it starts initially.
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_v2which 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.
Fixed in
ed25519_hup_v2branch(git-037e8763a7cb6358)Doesn't blindly accept new medium term signing key and cert if something is odd, computes and saves to disk the master public key if missing, covers the startup cases.
Sep 02 11:33:22.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. Sep 02 11:33:22.000 [warn] No key found in /root/torsrc/data/keys/ed25519_master_id_secret_key or /root/torsrc/data/keys/ed25519_master_id_public_key. Sep 02 11:33:22.000 [warn] Master public key was absent; inferring from public key in signing certificate and saving to disk. Cases 2 and 3: Sep 02 11:36:36.000 [warn] The signing cert we have was not signed with the master key we loaded! Sep 02 11:36:36.000 [warn] Problem reloading Ed25519 keys; still using old keys.Trac:
Status: needs_revision to needs_review-
I've tried sticking this stuff in https://phablab.krautspace.de/D2 . Maybe review the code there?
Replying to nickm:
I've tried sticking this stuff in https://phablab.krautspace.de/D2 . Maybe review the code there?
lgtm;
My two cents about phabricator, it was not a pleasant experience. The lack of context on where we are in the file makes it just unusable... I'm not a person that likes browser in general nor the whole dynamic Web experience so I'm probably not a good person to comment on this (or am I?) but reviewing code in a browser is just horrible.
moved to tpo/core/tor#16790 (closed)