Abnormal behavior when signing key expires if Ed25519 master ID key is offline (missing from /datadirectory/keys)
Using Tor 0.2.7.2-alpha from deb.tp.o/tor-nightly-master-wheezy on Debian Wheezy 64 bit.
Want to test the behavior in all possible scenarios for the offline key feature.
I have included in my torrc a short signing key lifetime, to see how Tor behaves. Previosuly I have exported the Ed25519 master id key from /var/lib/tor/keys.
torrc setting: SigningKeyLifetime 2 days
Tor started fine. Nothing in the log file was warning that the signing key and cert will expire in short time.
After about ~9 hours of usage, the relay went offline according to network status, but Tor was running on the server just fine. This is everything gathered from the logs:
Jul 27 21:16:00.000 [notice] Bootstrapped 100%: Done Jul 27 21:17:01.000 [notice] Performing bandwidth self-test...done. Jul 28 03:15:57.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 135 circuits open. I've sent 728.54 MB and received 735.52 MB. Jul 28 03:15:57.000 [notice] Circuit handshake stats since last time: 3409/3409 TAP, 4878/4878 NTor. Jul 28 03:15:57.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 3894 v4 connections; and received 0 v1 connections, 11 v2 connections, 0 v3 connections, and 4673 v4 connections. Jul 28 06:25:02.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. Jul 28 06:25:02.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Jul 28 06:25:02.000 [notice] Configuration file "/etc/tor/torrc" not present, using reasonable defaults. Jul 28 06:25:02.000 [notice] Opening Socks listener on 127.0.0.1:9050 Jul 28 06:25:02.000 [notice] Closing no-longer-configured Control listener on 127.0.0.1:9051 Jul 28 06:25:02.000 [notice] Closing no-longer-configured OR listener on :port Jul 28 06:25:02.000 [notice] Closing no-longer-configured OR listener on :port
12 hours later:
Jul 28 18:13:28.000 [warn] Couldn't find $HOME environment variable while expanding "~/.torrc"; defaulting to "". Jul 28 18:13:28.000 [notice] Configuration file "/etc/tor/torrc" not present, using reasonable defaults.
I have the torrc correct file in /etc/tor/torrc but Tor says it is not there. Nothing changed/altered it. Triple checked - it is there, it is correct and it was working just fine.
Tor also generated a 'keys' folder with full path: /root/.tor/keys which I didn't order. This folder contains these files: ed25519_master_id_public_key ed25519_master_id_secret_key ed25519_signing_cert ed25519_signing_secret_key
So, it created another (unrequested) Ed25519 identity. Wild thoughts about this.
- How was it able to write in /root/.tor/ ($HOME or ~/) and why this path? Shouldn't that be owned by root? I run Tor as debian-tor;
- Does it use this identity instead? There is nothing in the log files about the directory authorities rejecting this relay.
- Is it still publishing descriptors? Is it using the new unrequested Ed25519 identity? Or is it just publishing descriptors without Ed25519 identity (just with the old style RSA one)?
The previous folder, /var/lib/tor/keys is untouched. All files are there except master ID key which I exported offline, so here I found what was expected.
When Tor starts, it finds the relay's ID old style fingerprint based on the RSA key. Changed the log to info level, and based on this I assume it is actually publishing descriptors:
Jul 28 18:36:28.000 [info] init_keys(): Reading/making identity key "/var/lib/tor/keys/secret_id_key"... Jul 28 18:36:28.000 [info] tor_getpwnam(): Caching new entry debian-tor for debian-tor Jul 28 18:36:28.000 [info] tor_getpwnam(): Caching new entry debian-tor for debian-tor Jul 28 18:36:28.000 [info] init_keys(): Reading/making onion key "/var/lib/tor/keys/secret_onion_key"... Jul 28 18:36:28.000 [info] mark_my_descriptor_dirty(): Decided to publish new relay descriptor: set onion key
After few minutes, I get this warning (tor process still running): Jul 28 19:15:10.000 [warn] ConnLimit must be at least 32. Failing.
What needs to be fixed as fast as possible:
- Make sure Tor is aware and issues warnings in logs that the ed25519 signing key and key-cert are about to expire with reasonable time in advance it becomes effective. Don't start relay functionality if key-cert is expired, don't use it to build an invalid descriptor and don't generate unrequested new Ed25519 identity key;
- Make sure Tor disables relay functionality and defaults to PublishServerDescriptor 0 in case it has an Ed25519 public key in /datadirectory/keys but an expired signing key and key-cert. Leave client functionality running, since that should not be affected and maybe it is also used on that server;
- Don't generate Ed25519 identities unless requested or otherwise totally missing from /datadirectory/keys (example: when we configure a fresh relay from scratch with no identity). Do not proceed with generating a new Ed25519 identity if we already have an Ed25519 public key in /datadirectory/keys;
- Be aware if the directory authorities reject us because our RSA key <-> Ed25519 key pair changed. Stop publishing descriptors in this case and disable relay functionality and wait for user's action, or automatically generate new fresh full ID (both RSA id key and Ed25519 id key unencrypted) so the realy can be included in the consensus;