[tor-bugs] #16685 [Tor]: Abnormal behavior when signing key expires if Ed25519 master ID key is offline (missing from /datadirectory/keys)

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Jul 28 23:33:03 UTC 2015


#16685: Abnormal behavior when signing key expires if Ed25519 master ID key is
offline (missing from /datadirectory/keys)
------------------------------------------+--------------------------------
 Reporter:  s7r                           |          Owner:
     Type:  defect                        |         Status:  new
 Priority:  normal                        |      Milestone:  Tor:
Component:  Tor                           |  0.2.7.x-final
 Keywords:  ed25519 key, offline id keys  |        Version:  Tor:
Parent ID:                                |  0.2.7.2-alpha
                                          |  Actual Points:
                                          |         Points:
------------------------------------------+--------------------------------
 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
 <ipv6>:port
 Jul 28 06:25:02.000 [notice] Closing no-longer-configured OR listener on
 <ipv4>: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;

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16685>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list