Join the AMA (Ask Me Anything) with the Firefox leadership team to celebrate Firefox 20th anniversary and discuss Firefox’s future on Mozilla Connect. Mark your calendar on Thursday, November 14, 18:00 - 20:00 UTC!

搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

Protections against Tracking via HTTP/3 QUIC - Privacy

  • 无回复
  • 0 人有此问题
more options

Hello Mozilla Community,

I hope I am right with you guys to ask this question though it is a rather technical question. Please let me clarify that I am not a programmer myself or a network engineer but rather a hobbyist who is especially interested in privacy.

As I was reading about HTTP/3 and QUIC, I came across an academic paper called ""A QUIC Look at Web Tracking".

According to this paper QUIC gives web servers and third parties a good way to track users via the "source-address token" and the "server config" which are both stored on the client('s browser/machine). Now I know that this paper is from 2019 and concerns an older version of QUIC. However, in RFC 9000 "source address tokens" aka "address validation tokens" still exist and are especially used to establish future connections with 0-RTT instead of 1-RTT (see section 8.1 of RFC 9000). Though "server config" is not mentioned in RFC 9000, "transport parameters" is mentioned in section 7.4 and 18 of RFC 9000, which are also used for 0-RTT and are also stored on the client.

Neither RFC 9000 nor RFC 9114, which concerns HTTP3, address these privacy risks in more detail. Both seem to take only MITM attackers into account (see 9.5 in RFC 9000 and 10.11 in RC 9114) [as is done in a newer paper from 2022 Evaluating QUIC for Privacy Improvements Over Its Predecessors which however at least addresses the possibility of third party tracking under 5.1 3)].

I would also like to point towards RFC 9250 of May 2022, which concerns DNS over QUIC ("DoQ"). In Section 7 of RFC 9250 many privacy concerns regarding "0-RTT", "Session Resumption (Token)", "Address Validation Token" and "Long Duration Sessions due to QUIC's connection migration feature" are elaborated in more detail.

To sum up my understanding: - Using HTTP/3 or QUIC's "connection ID" for tracking should not be that viable, even if its function is to migrate connections in case of Layer-3/4 (IP address or Port) changes, because a connections life time is at least in firefox limited to 30 seconds (see Github neqo) so that a user should not be trackable for a longer period via the "connection ID". - However, longer tracking may be possible via "Session Resumption Tokens" and "Address Validation Tokens" (see Section 7.2 and 7.3 of RFC 9250; though I myself don't know the difference between these two) as well as via "transport parameters" (see "A QUIC Look at Web Tracking").

As mentioned in "A QUIC Look at Web Tracking", though a restart of the Browser seems to clear the cached state of prior QUIC connections (to my understanding the stored "tokens" and "transport parameters"), tracking via the above mentioned features of QUIC seems not unreasonable as many users today will not restart their browser, especially on mobile devices but also on desktops (3.7 and 5.1.2 of the paper).

As I was not able to find further information on this topic, I would be very happy to get some assurance that firefox is effectively preventing or at least impeding the tracking possibilities mentioned in RFC 9250 and the paper "A QUIC Look at Web Tracking".

Thank you very much for any reply or pointing me into the right direction (other sources on this topic or a more appropriate page to ask this question).

Hello Mozilla Community, I hope I am right with you guys to ask this question though it is a rather technical question. Please let me clarify that I am not a programmer myself or a network engineer but rather a hobbyist who is especially interested in privacy. As I was reading about HTTP/3 and QUIC, I came across an academic paper called "[https://www.researchgate.net/publication/334590434_A_QUIC_Look_at_Web_Tracking "A QUIC Look at Web Tracking"]. According to this paper QUIC gives web servers and third parties a good way to track users via the "source-address token" and the "server config" which are both stored on the client('s browser/machine). Now I know that this paper is from 2019 and concerns an older version of QUIC. However, in [https://www.rfc-editor.org/rfc/rfc9000.html RFC 9000] "source address tokens" aka "address validation tokens" still exist and are especially used to establish future connections with 0-RTT instead of 1-RTT (see section 8.1 of RFC 9000). Though "server config" is not mentioned in RFC 9000, "transport parameters" is mentioned in section 7.4 and 18 of RFC 9000, which are also used for 0-RTT and are also stored on the client. Neither RFC 9000 nor [https://www.rfc-editor.org/rfc/rfc9114.html RFC 9114], which concerns HTTP3, address these privacy risks in more detail. Both seem to take only MITM attackers into account (see 9.5 in RFC 9000 and 10.11 in RC 9114) [as is done in a newer paper from 2022 [https://allison-turner.github.io/media/Evaluating%20QUIC%20for%20Privacy%20Improvements%20Over%20Its%20Predecessors.pdf Evaluating QUIC for Privacy Improvements Over Its Predecessors] which however at least addresses the possibility of third party tracking under 5.1 3)]. I would also like to point towards [https://www.rfc-editor.org/rfc/rfc9250.html RFC 9250] of May 2022, which concerns DNS over QUIC ("DoQ"). In Section 7 of RFC 9250 many privacy concerns regarding "0-RTT", "Session Resumption (Token)", "Address Validation Token" and "Long Duration Sessions due to QUIC's connection migration feature" are elaborated in more detail. To sum up my understanding: - Using HTTP/3 or QUIC's "connection ID" for tracking should not be that viable, even if its function is to migrate connections in case of Layer-3/4 (IP address or Port) changes, because a connections life time is at least in firefox limited to 30 seconds (see [https://github.com/mozilla/neqo/issues/1412 Github neqo]) so that a user should not be trackable for a longer period via the "connection ID". - However, longer tracking may be possible via "Session Resumption Tokens" and "Address Validation Tokens" (see Section 7.2 and 7.3 of RFC 9250; though I myself don't know the difference between these two) as well as via "transport parameters" (see [https://www.researchgate.net/publication/334590434_A_QUIC_Look_at_Web_Tracking "A QUIC Look at Web Tracking"]). As mentioned in "A QUIC Look at Web Tracking", though a restart of the Browser seems to clear the cached state of prior QUIC connections (to my understanding the stored "tokens" and "transport parameters"), tracking via the above mentioned features of QUIC seems not unreasonable as many users today will not restart their browser, especially on mobile devices but also on desktops (3.7 and 5.1.2 of the paper). As I was not able to find further information on this topic, I would be very happy to get some assurance that firefox is effectively preventing or at least impeding the tracking possibilities mentioned in RFC 9250 and the paper "A QUIC Look at Web Tracking". Thank you very much for any reply or pointing me into the right direction (other sources on this topic or a more appropriate page to ask this question).

您需要登录才能回复。如果您还没账号,可以提出新问题