Privacy implications of the QUIC protocol [pdf]
petsymposium.org
Privacy implications of the QUIC protocol [pdf]
1–10 of 21 posts
Re: Privacy implications of the QUIC protocol [pdf]
#2in 2017 Brave disabled it:
> Back-story: Brave users reported ads getting past our ad-blocking shields in previous Chromium versions, beginning with reports of ads displaying on YouTube.com on October 11, 2016. uBlock Origin users had reported similar bugs. We discovered during testing that disabling QUIC seemed to stop these ads. As a result, we pushed an update to disable QUIC in Brave on January 25, 2017. This update appears to have temporarily abated the incoming bug reports about ads getting past our shields.
...
When we inspected web page traffic via chrome://net-internals, we discovered that QUIC requests were and still are being used for a majority of Google’s ad domains, including domains involved with bidding ...
Re: Privacy implications of the QUIC protocol [pdf]
#3in 2017 Brave disabled it: > Back-story: Brave users reported ads getting past our ad-blocking shields in previous Chromium versions, beginning with reports of ads displaying on YouTube.com on October 11, 2016. uBlock Origin users had reported similar bugs. We discovered during testing that disabling QUIC seemed to stop these ads. As a result, we pushed an update to disable QUIC in Brave on January 25, 2017. This upd…
Google software uses a google protocol to deliver google services. News at 11.
Is this the problem where we've shot ourselves in the foot securing communication to the point we can't block adequately now by tempering with traffic?
Re: Privacy implications of the QUIC protocol [pdf]
#4The network layer can already be used for tracking in multiple ways, including HTTPS sessions, ETags, and cached files with identifiers. When browsers partition the network layer they need to partition connection state as well, which includes QUIC/HTTP3 state. Safari already does this, and it looks to me like Chrome and Firefox are doing it too: https://www.jefftk.com/p/shared-cache-is-going-away
(Disclosure: I work on ads at Google, speaking only for myself)
Re: Privacy implications of the QUIC protocol [pdf]
#5"The source-address token is a unique, authenticated-encrypted data block provided by the server, which cannot be decrypted by the client. For the
purpose of IP address spoofing prevention, it contains
the users publicly visible IP address and a timestamp
as seen by the server."
Compare ...
http://curvecp.org/security.html
"Does CurveCP provide client address authentication?
No. IP addresses are not secure in any meaningful sense, and CurveCP does not attempt to make them secure. Servers that distinguish between clients must do so on the basis of long-term client public keys, not IP addresses."
Users can create new public keys anytime they want. They could, e.g., create one key for one purpose and another for another purpose. Over the years, I have noticed a common theme in the design of all djb software. Whether it is intentional or not, I do not know. Control rests with the user.
Re: Privacy implications of the QUIC protocol [pdf]
#6in 2017 Brave disabled it: > Back-story: Brave users reported ads getting past our ad-blocking shields in previous Chromium versions, beginning with reports of ads displaying on YouTube.com on October 11, 2016. uBlock Origin users had reported similar bugs. We discovered during testing that disabling QUIC seemed to stop these ads. As a result, we pushed an update to disable QUIC in Brave on January 25, 2017. This upd…
My question is why does their ad-blocking code work with one protocol and not another? Is their ad blocker running within Chrome's TCP/TLS stack instead of something higher-level like WebRequest (or maybe Chrome makes it impossible to do that)?
Re: Privacy implications of the QUIC protocol [pdf]
#7in 2017 Brave disabled it: > Back-story: Brave users reported ads getting past our ad-blocking shields in previous Chromium versions, beginning with reports of ads displaying on YouTube.com on October 11, 2016. uBlock Origin users had reported similar bugs. We discovered during testing that disabling QUIC seemed to stop these ads. As a result, we pushed an update to disable QUIC in Brave on January 25, 2017. This upd…
Google software uses a google protocol to deliver google services. News at 11. Is this the problem where we've shot ourselves in the foot securing communication to the point we can't block adequately now by tempering with traffic?
> Is this the problem where we've shot ourselves in the foot securing communication
Isn't that the goal? Everyone seems to think Google's innovations are gifts to the world. They are and always have been solutions to problems Google faces. The only reasons they're opensourced or community shared are to benefit Google. Anything beyond that is collateral benefit.
Re: Privacy implications of the QUIC protocol [pdf]
#8This is about Google's QUIC ("gQUIC") and is based on a version from 2018. It explains in the Related Work section at the end that the IETF QUIC protocol has different properties.
The trade discussed between keeping information for longer to make everything faster versus throwing it away frequently to avert tracking is _everywhere_ already. It's in your HTTP/1.1 web browser's Cookie behaviour, it's in the TLS implementation's resumption feature.
One piece of good news is that in the quest to speed things up putting the public keys into DNS means it's no longer practical to (as is discussed as a potential attack in this paper) give each client different keys so you can identify them that way. Because DNS is cache-based everybody receiving the same version of the cached data will see the same keys. This isn't a problem for good guys, everything works, but if your goal was to track people against their will it's a problem.
Re: Privacy implications of the QUIC protocol [pdf]
#9"The source-address token is a unique, authenticated-encrypted data block provided by the server, which cannot be decrypted by the client. For the purpose of IP address spoofing prevention, it contains the users publicly visible IP address and a timestamp as seen by the server." Compare ... http://curvecp.org/security.html "Does CurveCP provide client address authentication? No. IP addresses are not secure in any mea…
So, I think you've completely misunderstood what's going on here.
What QUIC is doing here is to prevent _spoofing_, whereas what DJB is talking about is the futility of using IP addresses as _identity_
Why does this matter? QUIC servers often have lots of bandwidth available to them and offer 0-RTT, so they can be used for an amplified denial-of-service attack. Bad Guys send packets "from" your IP address to the QUIC server. Without spoofing protection the QUIC server begins bombarding your IP address with stuff. Your network links saturate and you're effectively knocked out even though you did nothing to cause this.
Spoofing protection is provided in TCP (on any vaguely modern OS) but QUIC doesn't use TCP so it must roll its own protection and that's all this is for.
CurveCP has a 1-RTT setup penalty with a "Cookie" to prevent spoofing. If somebody wants to track you with CurveCP they'd be just as able to use this cookie as they would the QUIC "source address token". In both cases you could throw this away to prevent tracking, at a penalty of reducing performance because you'll have to do the startup dance all over again.
Re: Privacy implications of the QUIC protocol [pdf]
#10in 2017 Brave disabled it: > Back-story: Brave users reported ads getting past our ad-blocking shields in previous Chromium versions, beginning with reports of ads displaying on YouTube.com on October 11, 2016. uBlock Origin users had reported similar bugs. We discovered during testing that disabling QUIC seemed to stop these ads. As a result, we pushed an update to disable QUIC in Brave on January 25, 2017. This upd…
Google software uses a google protocol to deliver google services. News at 11. Is this the problem where we've shot ourselves in the foot securing communication to the point we can't block adequately now by tempering with traffic?
Per the Brave article blocking is perfectly possible and works fine, it was just their blocker implementation not being ready for a different protocol.