Audit HTTP/2 and SPDY if needed
HTTP/2 is enabled in Firefox 38. We should make sure it adheres to our design specifcation. If not we need to either patch the problematic things or switch them of via preferences. Related: #6101 (moved) and #4100 (moved).
Activity
Trac:
Description: HTTP/2 is enabled in Firefox 38. We should make sure it adheres to our design specifcation. If not we need either patch the problematic things or switch them of via preferences. Related: #6101 (moved) and #4100 (moved).to
HTTP/2 is enabled in Firefox 38. We should make sure it adheres to our design specifcation. If not we need to either patch the problematic things or switch them of via preferences. Related: #6101 (moved) and #4100 (moved).
Looking over Georg and my mails with Mark Nottingham, our concerns then were:
- Long-lived connections, especially without proper first party isolation in terms of connection re-use.
- 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)
- 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).
-
Note: don't forget the keep-alive audit for SPDY (see: #4100 (moved)).
Trac:
Cc: mcs to mcs, dcf@torproject.org
