Opened 4 years ago

Last modified 2 years ago

#15938 new defect

HS descriptor cache leaks timing information to local users

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, tor-client needs-design maybe-bad-idea
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by teor)

Anyone who can connect to a tor client can discover which HSs have been accessed recently, by running a timing attack against the HS cache. Cached descriptors return much faster than uncached descriptors.

This may be possible through browser JavaScript attempting HS connections and timing the responses.

An observer on the network or in control of an HSDir could potentially enhance this timing attack with network request correlation.

Yawning suggests a cache for each stream-isolation context, to avoid this issue.

Each stream-isolation cache would most likely have 0 or 1 HS descriptor in it - 0 if the URL is not a HS, and 1 if it is.

Child Tickets

Change History (14)

comment:1 Changed 4 years ago by dgoulet

Keywords: tor-hs added
Milestone: Tor: 0.2.???Tor: 0.2.7.x-final

comment:2 Changed 4 years ago by nickm

The suggestion is for a per-{stream-isolation} cache, not a {per-stream}-isolation cache, yeah?

comment:3 Changed 4 years ago by cypherpunks

Please no more ways to make Tor spam the HSDirs with requests.

comment:4 Changed 4 years ago by teor

Description: modified (diff)

nickm: yes, a cache for each stream-isolation context.

cyupherpunks: the extra load is likely to be minimal - the separate caches would only load the same descriptor when there are multiple stream-isolation contexts accessing the same hidden service.
This is only likely in the following circumstances:

  • multi-user SOCKS connections to Tor clients
  • multiple websites loading resources (e.g. ads) from the same hidden service
  • timing-based enumeration attacks on the HS descriptor cache

It's this last issue we want to protect against.

comment:5 Changed 4 years ago by dgoulet

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

comment:6 Changed 4 years ago by nickm

Keywords: SponsorU removed
Sponsor: SponsorU

Bulk-replace SponsorU keyword with SponsorU field.

comment:7 Changed 4 years ago by dgoulet

Keywords: SponsorR removed
Sponsor: SponsorUSponsorR

comment:8 Changed 4 years ago by dgoulet

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

comment:9 Changed 3 years ago by dgoulet

Sponsor: SponsorRSponsorR-can

Move those from SponsorR to SponsorR-can.

comment:10 Changed 3 years ago by teor

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

Milestone renamed

comment:11 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:12 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:13 Changed 2 years ago by dgoulet

Keywords: tor-client added
Severity: Normal
Sponsor: SponsorR-can

comment:14 Changed 2 years ago by nickm

Keywords: needs-design maybe-bad-idea added
Note: See TracTickets for help on using tickets.