[tor-bugs] #14952 [Tor Browser]: Audit HTTP/2

[Tor Bug Tracker & Wiki]

#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:
       Points:               |
-----------------------------+----------------------

Comment (by mikeperry):

 Looking over Georg and my mails with Mark Nottingham, our concerns then
 were:
 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
 6.3.2)
 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
 things are possible with Javascript (or even by simply shoving a bunch of
 junk inside an html comment in a hidden element), but people are able to
 disable Javascript, and static content-based mechanisms will also show
 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