Keep a separate onion-service cache for each isolation context
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.
Activity
changed milestone to %Tor: unspecified in legacy/trac
added component::core tor/tor in Legacy / Trac maybe-bad-idea in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac needs-design in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac tor-client in Legacy / Trac tor-hs in Legacy / Trac type::defect in Legacy / Trac labels
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.
Trac:
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.
to
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.
mentioned in issue legacy/trac#20555 (moved)
moved from legacy/trac#15938 (moved)
added Bug label and removed 1 deleted label
