[tbb-bugs] #14952 [Tor Browser]: Audit HTTP/2
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Feb 19 21:39:35 UTC 2015
#14952: Audit HTTP/2
Reporter: gk | Owner: tbb-team
Type: task | Status: new
Priority: normal | Milestone:
Component: Tor Browser | Version:
Resolution: | Keywords: ff38-esr
Actual Points: | Parent ID:
Comment (by mikeperry):
Looking over Georg and my mails with Mark Nottingham, our concerns then
1. Long-lived connections, especially without proper first party isolation
in terms of connection re-use.
2. We probably want to disable server push, due to cache inference attacks
(see: https://gnunet.org/sites/default/files/uzunov2013torspdy.pdf section
3. PING and SETTINGS timing side channels.
I had this to say about PING and SETTINGS:
> Relatedly, I'm somewhat worried about the bidirectional nature of PING
and SETTINGS from the tor-specific perspective. Because these can be sent
async by the server and are acked immediately by the client, they might be
able to introduce a timing signature by the server beyond what is
contained in response to active requests from the client.. Granted, such
junk inside an html comment in a hidden element), but people are able to
load progress indication in the UI.
> Therefore, In Tor Browser, I'd be tempted to close the connection if I
got more than some frequency of PING or SETTINGS updates from the server,
especially in the absence of other activity.
Mark said that closing such connections seemed fine, but we'd have to be
careful about content elements just reopening them either through JS or
dynamic CSS-based element loads. One option for that is to disable
browser-based JS/HTML network activity in inactive tabs using Firefox's
request filter APIs.
We also discussed playing with HTTP/2's various batching and padding
parameters as another possible defense against website traffic
fingerprinting, but I'm not sure there is enough there already to make
this very useful beyond the types of things that our pipelining defense
already does, and we still need more research in this area to know what
we'd want to add/change and how. He suggested waiting for HTTP/3 for
requesting such things in spec form, since there will be resistance to
late spec changes that may change cost profiles for the server side,
especially for deployment (since that has already begun).
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14952#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs