Opened 4 years ago

Closed 4 years ago

#16530 closed defect (fixed)

uploaded a descriptor with a Ed25519 key but the <rsa,ed25519> keys don't match what they were before.

Reported by: arma Owned by:
Priority: Immediate Milestone: Tor: 0.2.7.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: TorCore201507, tor-auth
Cc: inf0 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

On moria1, running Tor 0.2.7.1-alpha-dev (git-130a9c0ac8aa13ac), I get these each vote time.

Jul 08 22:50:29.411 [warn] Router $A69221A7EC7498D2F88A0FB795261013FA36CAAE~Truie at 198.50.156.78 uploaded a descriptor with a Ed25519 key but the <rsa,ed25519> keys don't match what they were before.
Jul 08 22:50:29.411 [warn] Router $CF6D0AAFB385BE71B8E111FC5CFF4B47923733BC~Faravahar at 154.35.175.225 uploaded a descriptor with a Ed25519 key but the <rsa,ed25519> keys don't match what they were before.

Am I supposed to do something?

Child Tickets

TicketStatusOwnerSummaryComponent
#16580closednickmReload keypins on SIGHUP? Or provide some other way to undo a single keypin?Core Tor/Tor
#16581closedAlways load public master ed25519 key from disk, check for match with signing certCore Tor/Tor
#16582closedDistinguish ENOENT from other error cases when loading keys.Core Tor/Tor

Change History (9)

comment:1 Changed 4 years ago by nickm

Priority: normalblocker

This means that your authority believes that these two routers previously had different Ed25519 keys to go with their RSA identity keys, and they changed them. So it's rejecting the descriptors as hopeless.

Dgoulet ran into this on his relay.

There are a few possible explanations:

  1. The operators of these routers accidentally deleted or replaced ed25519 keys somehow. (If this is the case, we should make these accidents much harder to trigger.)
  2. There's a bug in the relay code that deletes or replaces the ed25519 key without the relay operator knowing. (If this is the case, we need to fix this before releasing 0.2.7.2-alpha or relays will fall off the network)
  3. There's a bug in the authority key-pinning code that makes us think the key changed when it didn't. (If this is the case, we need to fix it before too many authorities upgrade, or they will kick all the >= 0.2.7.2-alpha relays off the network)

I'm calling this a blocker on 0.2.7.2-alpha, in case it's case 2 or case 3.

comment:2 Changed 4 years ago by nickm

hm, Quite confusing.

Looking at the descriptors from Truie (dgoulet's server) on archive.torproject.org, it does indeed seem that the master-key-ed25519 field did indeed change around 26 June.

But the ed25519_master_id_* files on his relay have an mtime from 2 June... but they're matching the descriptors I'm seeing from 26 June and later.

comment:3 Changed 4 years ago by nickm

Roger, are those the only two that you see, or are you getting more of them?

comment:4 Changed 4 years ago by arma

Just these two.

comment:5 Changed 4 years ago by nickm

"Maybe there was some bug where it generated a master key and saved it to disk but then it generated another that was attached to the signing key and then didn't look at the one on disk again until it was time to generate another key."

comment:6 Changed 4 years ago by nickm

We've noticed that the key on Truie was generated on the same day that dgoulet was running his exciting "start with very restricted numbers of fds" experiments. It could be related...

comment:7 Changed 4 years ago by arma

Cc: inf0 added

Faravahar is famous for having weird network behaviors, like failing to make outgoing connections. Who knows, maybe it also has weird file system behaviors.

comment:8 Changed 4 years ago by nickm

Hmmm. So here's how I'm leaning on this issue for 0.2.7.2-alpha:

  • Ensure that there is a way for authority operators to un-pin keys in cases like this.
  • On a relay, *always* read at least the public master key, and ensure that it matches any certificate we send out.

comment:9 Changed 4 years ago by nickm

Keywords: TorCore201507 added
Resolution: fixed
Status: newclosed

I merged a branch to deal with this in 0.2.7.2-alpha

Note: See TracTickets for help on using tickets.