Opened 4 years ago

Last modified 2 years ago

#17957 new enhancement

Detect stolen onion service key

Reported by: ess2 Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: key-observatory, tor-hs, needs-proposal, key-theft, intro
Cc: Actual Points:
Parent ID: Points: 6
Reviewer: Sponsor:

Description

Would it be possible to add a detection mechanism for stolen onion service keys?

How it could work (I know very little about Tor internals):
A HSDir could tell the tor client that someone else with the same key announced a hidden service just minutes ago.
To determine that it was someone else, a random number could be sent with each announcement of an onion service, and that number randomly changes every time tor is restarted. If tor isn't restarted but the HSDir tells the announcing tor client that a different number was used to announce the onion service before, one could reasonably suspect that the key has been compromised. The user could then try to rule out a false positive, and get a new key.

It might be problematic that the HSDir can lie to .onions it doesn't like, but as long as no automatic action but the notification is done, this shouldn't cause much harm.

Child Tickets

Change History (5)

comment:1 Changed 4 years ago by teor

Keywords: hs key-observatory added; .onion hidden service removed
Milestone: Tor: 0.2.8.x-final
Parent ID: #17242

Tor already has a field for this, each hidden service descriptor has a monotonically strictly increasing sequence number.

Descriptors created using a stolen key are somewhat more likely to be rejected in the first period, if setup naïvely. The newly created hidden service will use a sequence number of 1, whereas the existing hidden service will have incremented for each descriptor change in the period.

If we randomised the sequence number, a hidden service could check that the descriptor corresponds to the sequence number it posted.

Alternately, the hidden service could check the hash of the descriptor against the one it posted.

Either of these schemes would have to allow for OnionBalance and similar load-balancing schemes.

A (python-based) ControlPort client could do these checks, maybe that would be the best way to implement this feature.

(See also proposal 224 tickets like #17242.)

comment:2 Changed 4 years ago by teor

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

comment:3 Changed 4 years ago by asn

Keywords: tor-hs added
Milestone: Tor: 0.2.9.x-finalTor: 0.2.???
Points: medium

Triaging this and moving it out of 0.2.9.x . This is not in our plans currently, and it would need a formal proposal for sure. Feel free to put it back to 0.2.9.x if you think it's viable.

comment:4 Changed 3 years ago by dgoulet

Keywords: needs-proposal added; hs removed
Milestone: Tor: 0.2.???Tor: unspecified
Parent ID: #17242
Points: medium6

Unparenting as this is more of a research and needs-proposal change then a "must have feature" for proposal 224.

comment:5 Changed 2 years ago by nickm

Keywords: key-theft intro added
Note: See TracTickets for help on using tickets.