Opened 4 years ago

Closed 3 years ago

Last modified 17 months ago

#18812 closed defect (fixed)

[warn] Tried connecting to router at 81.7.17.171:443, but identity key was not as expected: wanted 00C4B4731658D3B4987132A3F77100CFCB190D97 but got CFECDDCA990E3EF7B7EC958B22441386B6B8D820.

Reported by: arma Owned by: teor
Priority: Medium Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version: Tor: 0.2.8.1-alpha
Severity: Normal Keywords: fallback, must-fix-before-028-stable, easy, TorCoreTeam201606
Cc: Actual Points: 0.5
Parent ID: Points: 1
Reviewer: Sponsor:

Description

I'm running git master, but I think this applies to Tor 0.2.8.2-alpha. On bootstrap, I got

[...]
Apr 13 03:17:50.542 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Apr 13 03:17:50.620 [warn] Tried connecting to router at 81.7.17.171:443, but identity key was not as expected: wanted 00C4B4731658D3B4987132A3F77100CFCB190D97 but got CFECDDCA990E3EF7B7EC958B22441386B6B8D820.
Apr 13 03:17:52.147 [notice] Bootstrapped 40%: Loading authority key certs
[...]

So I think everything is going according to plan (cool, I even used a fallback dir!), except my fallback dir seems to have changed its key since it went into fallback_dirs.inc.

Maybe it isn't so reliably stable after all? :) :/

I wonder if we should consider a) doing periodic full checks of the fallback relays, to catch issues like this one preemptively, and then b) making the warning less scary for normal users.

Child Tickets

Change History (10)

comment:1 Changed 4 years ago by nickm

Cc: teor added
Keywords: fallback added

comment:2 Changed 4 years ago by teor

Keywords: must-fix-before-028-rc easy added
Points: small
Status: newneeds_information
Version: Tor: 0.2.8.1-alpha

Analysis

I suspect the operator changed keys (unnecessarily) in January:
https://lists.torproject.org/pipermail/tor-relays/2016-January/008466.html
This is unfortunate, as they only opted-in in December:
https://lists.torproject.org/pipermail/tor-relays/2015-December/008365.html
I emailed the operator to confirm the key change:
https://lists.torproject.org/pipermail/tor-relays/2016-April/009121.html

Fallback List Fix

This particular relay was excluded when I rebuilt the list of fallback directories for 0.2.8-rc, as its key / IP combination doesn't match the one in the whitelist.
See my branch fallbacks-201604-v9 on https://github.com/teor2345

Normally, we would have required a longer stability period (120 days), but I had to reduce the stability period to 7 days, as no current released tor version has the fix for #18050. We'll fix this for 0.2.9 in #18828. Of course, this doesn't prevent operators changing keys in the future - it just checks if they have in the past.

Fallback Check Fix

I have reopened #18177 to ask atagar to include ORPort and key checks in the existing DocTor fallback directory checks.

Log Message Fix

I'm happy to make a fix to the log message in this ticket, and get it in 0.2.8.

Do you have a suggested "less scary" wording, arma?
I'd go with:

"[notice] The relay at IP:ORPort has changed its key from A to B. Trying a different relay."

These messages will only occur on bootstrap, so I think it's ok to leave them at notice.
But there may be a few if a few fallbacks change keys.
And tails users will get then on every boot. Should we reduce them to info?

Note that this wording and the change of log level will apply even if the relay is a guard.
Is this what we want? Or should we change it only for the fallback case?
(We can do this, there are functions that tell us when we're bootstrapping.)
If so, I'd say "info" for fallbacks, and "warn" for guards/authorities.

comment:3 Changed 4 years ago by teor

Fallback List Creation Fix

The updateFallbackDirs.py script now logs a warning when a fallback's IP (v4 or v6) and ORPort (v4 or v6) match, but the key id does not.

We can deal with these the same way we deal with added or missing IPv6 addresses (or any other fallback detail change):

  • the script excludes the relay automatically because it doesn't match the whitelist entry exactly,
  • someone contacts the operator to confirm whether the change is permanent and will last 2 years,
  • if they are stable, we update the whitelist with the relay's new details.

I added a commit to my branch fallbacks-201604-v9 which checks for key mismatches. I also upgraded any detail change from the whitelist to a warning. Looks like I have some other operators to contact about IPv4 changes:

WARNING::6DE61A6F72C1E5418A66BFED80DFB63E4C77668F excluded: has it changed IPv4 from 85.25.138.93 to 91.121.84.137?
WARNING::00C4B4731658D3B4987132A3F77100CFCB190D97 excluded: has OR 81.7.17.171:443 changed fingerprint to CFECDDCA990E3EF7B7EC958B22441386B6B8D820?
WARNING::00C4B4731658D3B4987132A3F77100CFCB190D97 excluded: has OR [2a02:180:1:1::517:11ab]:443 changed fingerprint to CFECDDCA990E3EF7B7EC958B22441386B6B8D820?
WARNING::774555642FDC1E1D4FDF2E0C31B7CA9501C5C9C7 excluded: has it changed IPv4 from 188.166.123.212 to 188.166.133.133?

Fortunately, my mail client is good at searching for 40-character hex strings.

comment:4 in reply to:  2 Changed 4 years ago by teor

Owner: set to teor
Status: needs_informationassigned

Replying to teor:

Log Message Fix

I'm happy to make a fix to the log message in this ticket, and get it in 0.2.8.

Do you have a suggested "less scary" wording, arma?
I'd go with:

"[notice] The relay at IP:ORPort has changed its key from A to B. Trying a different relay."

These messages will only occur on bootstrap, so I think it's ok to leave them at notice.
But there may be a few if a few fallbacks change keys.
And tails users will get then on every boot. Should we reduce them to info?

Note that this wording and the change of log level will apply even if the relay is a guard.
Is this what we want? Or should we change it only for the fallback case?
(We can do this, there are functions that tell us when we're bootstrapping.)
If so, I'd say "info" for fallbacks, and "warn" for guards/authorities.

This is all we need to do to fix this now. I can do it.

comment:5 Changed 4 years ago by nickm

Keywords: TorCoreTeam201605 added

Calling all non-needs_information tickets for May.

comment:6 Changed 4 years ago by isabela

Points: small1

comment:7 Changed 3 years ago by nickm

Keywords: TorCoreTeam201605 removed

Remove "TorCoreTeam201605" keyword. The time machine is broken.

comment:8 Changed 3 years ago by teor

Actual Points: 0.5
Keywords: must-fix-before-028-stable TorCoreTeam201606 added; must-fix-before-028-rc removed
Status: assignedneeds_review

Please see my branch bug18812 on https://github.com/teor2345/tor.git

It replaces the warning with an info-level log, with additional text saying we'll just try another fallback.

comment:9 Changed 3 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

merging; fixed space a little. Thanks!

comment:10 Changed 17 months ago by teor

Cc: teor removed

Remove useless CC

Note: See TracTickets for help on using tickets.