4 ms·

I appreciate you mentioning the Session ID and Session Ticket scenarios. Those can be disabled though, correct? HTTP/2 over cleartext TCP is also possible? M

I appreciate you mentioning the Session ID and Session Ticket scenarios. Those can be disabled though, correct? HTTP/2 over cleartext TCP is also possible? Maybe still some increase in correlation risk due to those? Do you think the Alt-Svc scenario we are talking about would guarantee two separate HTTP/2 connections?

cesarb 11y ago
> I appreciate you mentioning the Session ID and Session Ticket scenarios. Those can be disabled though, correct? Yes, the server can ignore both and always start a new session. And you could modify a client to never send either, but if you are already modifying the client code you could also modify it to always use a separate connection. > HTTP/2 over cleartext TCP is also possible? In theory yes, in practice most will only implement it over TLS, to avoid middleboxes breaking it. TLS-intercepting middleboxes won't negotiate HTTP/2, so it'll fallback cleanly in that case. > Do you think the Alt-Svc scenario we are talking about would guarantee two separate HTTP/2 connections? Alt-Svc to a different hostname will always use TLS. From the draft: "Clients MUST NOT use alternative services with a host that is different than the origin's without strong server authentication; this mitigates the attack described in Section 9.2. One way to achieve this is for the alternative to use TLS with a certificate that is valid for that origin." And with current TLS, the hostname is sent on the handshake (SNI), so it can't use the same session for different hostnames.
- WireWrap 11y ago
  I think the security.ssl.disable_session_identifiers pref in Gecko browsers is meant to allow for it without modifying the code, and I haven't spotted a similarly easy way of controlling HTTP/2 connections. Otherwise, point taken. Is there anything we haven't discussed that would fall within the HTTP/2 spec's "Reusing connections for different origins allows tracking across those origins." warning?

cesarb 11y ago

> I appreciate you mentioning the Session ID and Session Ticket scenarios. Those can be disabled though, correct? Yes, the server can ignore both and always start a new session. And you could modify a client to never send either, but if you are already modifying the client code you could also modify it to always use a separate connection. > HTTP/2 over cleartext TCP is also possible? In theory yes, in practice most will only implement it over TLS, to avoid middleboxes breaking it. TLS-intercepting middleboxes won't negotiate HTTP/2, so it'll fallback cleanly in that case. > Do you think the Alt-Svc scenario we are talking about would guarantee two separate HTTP/2 connections? Alt-Svc to a different hostname will always use TLS. From the draft: "Clients MUST NOT use alternative services with a host that is different than the origin's without strong server authentication; this mitigates the attack described in Section 9.2. One way to achieve this is for the alternative to use TLS with a certificate that is valid for that origin." And with current TLS, the hostname is sent on the handshake (SNI), so it can't use the same session for different hostnames.

WireWrap 11y ago
I think the security.ssl.disable_session_identifiers pref in Gecko browsers is meant to allow for it without modifying the code, and I haven't spotted a similarly easy way of controlling HTTP/2 connections. Otherwise, point taken. Is there anything we haven't discussed that would fall within the HTTP/2 spec's "Reusing connections for different origins allows tracking across those origins." warning?