[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #16685 [Tor]: Abnormal behavior when signing key expires if Ed25519 master ID key is offline (missing from /datadirectory/keys)
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs