[tor-bugs] #15938 [Tor]: HS descriptor cache leaks timing information to local users

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri May 8 12:29:14 UTC 2015


#15938: HS descriptor cache leaks timing information to local users
------------------------+----------------------------------------
     Reporter:  teor    |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  SponsorR, SponsorU, tor-hs
Actual Points:          |  Parent ID:
       Points:          |
------------------------+----------------------------------------

Old description:

> 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 per-stream-isolation cache to avoid this issue.
>
> Each TorBrowser-isolated 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.

New description:

 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.

--

Comment (by teor):

 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15938#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list