Opened 5 years ago

Last modified 2 years ago

#11458 new enhancement

A newer signing cert should innoculate us against older ones?

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal tor-client tor-dirauth security certificates
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Sometime in the past year or two somebody might have stolen 7 of the 9 active directory signing keys. They don't expire for several months or more.

If the existing directory authorities rotate to new signing keys, that doesn't really change the fact that older ones remain valid.

If we change Tor to look at its cached-certs and refuse to believe in a signing key if it's convinced there's a newer one, then we can invalidate older ones by generating newer ones.

That approach wouldn't protect users who are bootstrapping for the first time, but it would protect them if they'd already bootstrapped. Is this a worthwhile improvement?

Note that we'd have to sort out edge cases like #11457 -- basically in this case it would mean that if you ever generate a signing key too far in the future and then also want to go back to an earlier one, you're fucked. But has anybody ever needed to do that?

To tolerate rotation better, we'd want the logic to be something like the suggested fix in #11454: only disbelieve a cert if a) we have a newer one and b) the one we're disbelieving is sufficiently older than now.

We could also think about shipping with a cached-certs file to keep raising the bar as users upgrade.

Child Tickets

Change History (16)

comment:1 Changed 5 years ago by nickm

It seems to me that the answer here has to be some kind of revocation mechanism.

comment:2 Changed 5 years ago by nickm

Keywords: 026-triaged-1 added

comment:3 Changed 4 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final
Status: newneeds_review

comment:4 Changed 4 years ago by nickm

Status: needs_reviewnew

comment:5 Changed 4 years ago by nickm

Status: newassigned

comment:6 Changed 4 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:7 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

comment:8 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:9 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:10 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:11 Changed 2 years ago by nickm

Keywords: 027-triaged-in added

comment:12 Changed 2 years ago by nickm

Keywords: 027-triaged-in removed

comment:13 Changed 2 years ago by nickm

Keywords: 027-triaged-1-out removed

comment:14 Changed 2 years ago by nickm

Keywords: 026-triaged-1 removed

comment:15 Changed 2 years ago by nickm

Status: assignednew

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

comment:16 Changed 2 years ago by nickm

Keywords: tor-client tor-dirauth security certificates added
Severity: Normal
Note: See TracTickets for help on using tickets.