Opened 5 years ago

Closed 5 years ago

Last modified 3 years ago

#11464 closed defect (implemented)

Implement a client-side blacklist for authority certificate signing keys

Reported by: nickm Owned by:
Priority: High Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client, 024-backport, 023-backport, heartbleed, 2016-bug-retrospective
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

For background see https://lists.torproject.org/pipermail/tor-dev/2014-April/006663.html and https://lists.torproject.org/pipermail/tor-dev/2014-April/006664.html .

We should have a way to blacklist authority signing keys at the client-side. In the longer term, we should implement a full on revocation (see #11458), but for now, we can at least revoke certificates hard by blacklisting them client-side.

I think that the right way to do this is to have any signing keys on that blacklist always have their signatures treated as "BAD". This doesn't prevent us from fetching or holding those certs, and so doesn't mess up our cert fetching code.

Obviously, any fix here is a backport candidate.

Child Tickets

Attachments (2)

badcerts-2014-04-14.tar.gz (11.9 KB) - added by nickm 5 years ago.
list of bad certs, from arma
tor-certkey.c (1.3 KB) - added by nickm 5 years ago.
kludgy tool to find cert signing keys.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 5 years ago by nickm

Summary: Implement a blacklist for authority certificate signing keysImplement a client-side blacklist for authority certificate signing keys

comment:2 Changed 5 years ago by nickm

Status: newneeds_review

There's code in branch "bug11464_023". This needs review and testing, but it also needs an actual list of signing key digests to blacklist.

Changed 5 years ago by nickm

Attachment: badcerts-2014-04-14.tar.gz added

list of bad certs, from arma

Changed 5 years ago by nickm

Attachment: tor-certkey.c added

kludgy tool to find cert signing keys.

comment:3 Changed 5 years ago by nickm

I've used the above file and the above tool to generate a list of signing keys, and added it to the branch.

comment:4 Changed 5 years ago by andrea

I think this looks okay; my reading of networkstatus_check_consensus_signature() is that if insufficiently many good signatures exist, the client will reject the consensus and not function? I presume these have already been rotated and we won't horribly break any clients by merging this unless someone tries to use stolen signing keys to do something nasty to them?

comment:5 in reply to:  4 Changed 5 years ago by nickm

Replying to andrea:

I think this looks okay; my reading of networkstatus_check_consensus_signature() is that if insufficiently many good signatures exist, the client will reject the consensus and not function?

Yes.

I presume these have already been rotated and we won't horribly break any clients by merging this unless someone tries to use stolen signing keys to do something nasty to them?

We're still waiting on dizum and dannenberg.

comment:6 Changed 5 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Merged to 0.2.3 and forward.

comment:7 Changed 3 years ago by nickm

Keywords: 2016-bug-retrospective added

Mark bugs for 2016 bug retrospective based on hand-examination of changelogs for 0.2.5 onwards.

comment:8 Changed 3 years ago by nickm

Mark bugs for 2016 bug retrospective based on hand-examination of changelogs for 0.2.5 onwards.

comment:9 Changed 3 years ago by nickm

Mark bugs for 2016 bug retrospective based on hand-examination of changelogs for 0.2.5 onwards.

Note: See TracTickets for help on using tickets.