Website Fingerprinting on Early QUIC Traffic(arxiv.org)
arxiv.org
Website Fingerprinting on Early QUIC Traffic
https://arxiv.org/abs/2101.11871
127 comments
We had also investigated the differences in fingerprintability between HTTP/QUIC and HTTPS (WF in the Age of QUIC, PETS'21). We had found equivalent fingerprintability with deep-learning classifiers when eavesdropping on the traffic through Wireguard. It's interesting though to see the stark difference they found between fingerprinting HTTP/QUIC and HTTPS when using only the first ~40 packets. The trends in those early packets had also allowed us to easily differentiate between the two types of traffic over the VPN.
Our paper, in case you want to read more on this area: https://petsymposium.org/2021/files/papers/issue2/popets-202...
Our paper, in case you want to read more on this area: https://petsymposium.org/2021/files/papers/issue2/popets-202...
I assume most websites have a unique public IP, once you know the destination address, isn't it easy to infer the visited website.
If you don't use shared hosting it is very easy, and even if you do use shared hosting it is fairly easy:
"What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...
"What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...
[deleted]
"allowing adversaries to infer the users' visited websites by eavesdropping on the transmission channel."
Ah, ok, that kind of fingerprinting. I suppose then this might be where our local ISP's find a way to replace their now threatened DNS query sniffing. Assuming 95.4% accuracy means what I think it does, that's pretty impressive.
Ah, ok, that kind of fingerprinting. I suppose then this might be where our local ISP's find a way to replace their now threatened DNS query sniffing. Assuming 95.4% accuracy means what I think it does, that's pretty impressive.
Hah. I accidentally read "advertisers" instead of "adversaries". Still valid I guess...?
They might as well be synonyms at this point.
I skimmed the paper and read it as an improved passive attack against ESNI and Do{T,H} setups. There's nothing really new, other than QUIC making it easier to identify the destinations.
Traffic analysis is a harsh villain.
Traffic analysis is a harsh villain.
Sadly, eSNI is dead in the water, but an alternative is being worked on. It'll just take longer for it to come to market.
When you say ESNI is dead in the water, do you mean that it’s moved on to being ECH (encrypted client hello)? Or do you mean the entire concept is dead? If the latter, what makes you say that?
I meant the conversion to ECH. eSNI has had proof-of-concept support built in for a while and, had it worked out better, could have been deployed publicly any day now. The new extension, ECH, will need significant testing and development until it can reach the same level of support again.
The concept is the clear and obvious way forward in web security; what's the point in encrypting DNS when the SNI is still readable. I'm also glad that eSNI has been dropped because of the obvious flaws found in it rather than continuing attempts to secure an inherently flawed protocol. However, this does mean that deployment will take longer than previously estimated, which is kind of a bummer.
The concept is the clear and obvious way forward in web security; what's the point in encrypting DNS when the SNI is still readable. I'm also glad that eSNI has been dropped because of the obvious flaws found in it rather than continuing attempts to secure an inherently flawed protocol. However, this does mean that deployment will take longer than previously estimated, which is kind of a bummer.
I bet you could get 95.4% accuracy by simply looking at the IP addresses that users connect to.
Each webpage comes from an IP, but includes subresources from a whole set of domains. I would guess that for the vast majority of web sites, that set of domains is unique.
Each webpage comes from an IP, but includes subresources from a whole set of domains. I would guess that for the vast majority of web sites, that set of domains is unique.
Here is a presentation and blog post where they did a study about this:
"What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...
"What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...
> The majority of websites (95.7%) have a unique PLF, suggesting there is a risk of identifying that a user is visiting the site solely from a list of contacted IP addresses
So, yes, IP addresses are plenty sufficient to figure out what someone is browsing.
So, yes, IP addresses are plenty sufficient to figure out what someone is browsing.
I'm guessing not, as they say "whereas only 60.7% when on HTTPS".
[deleted]
It's odd state of the world where we will have to add significant amounts of noise to prevent browsers from revealing what site they are visiting because of traffic request protocols getting too efficient and browsers trying to be efficient in predictable ways.
Remember how truly secure channels keep transmitting random noise at a constant rate when they are not transmitting encrypted messages at the same rate.
Anything which is non-uniform is an attack surface. If an efficiency improvement makes things more predictable, then it adds a possibility of a new snooping attack. All your interactions have to be as inefficient as your most inefficient interaction, else an adversary can tell them apart
Anything which is non-uniform is an attack surface. If an efficiency improvement makes things more predictable, then it adds a possibility of a new snooping attack. All your interactions have to be as inefficient as your most inefficient interaction, else an adversary can tell them apart
I never thought about this. Also, I find it depressing.
Basically my browser needs to "keep watching some YouTube stream", so an attacker can't figure out that I switched to reading emails.
Basically my browser needs to "keep watching some YouTube stream", so an attacker can't figure out that I switched to reading emails.
This applies if you don't want these two activities to be told apart badly enough.
Most of the time, it's not the case, and just the fact you are checking emails does not give your adversaries enough information to care about. Being uninteresting and unimportant is one of the best possible defenses. The higher the stakes go, the more minor details become important to conceal. These constant-rate white-noise channels are used by military and intelligence.
Most of the time, it's not the case, and just the fact you are checking emails does not give your adversaries enough information to care about. Being uninteresting and unimportant is one of the best possible defenses. The higher the stakes go, the more minor details become important to conceal. These constant-rate white-noise channels are used by military and intelligence.
There is a middle ground, where you have a couple of tiers.
This is core to the onion routing protocol.
And a huge knowledge hole on the p2p/dweb and IETFF people both.
And a huge knowledge hole on the p2p/dweb and IETFF people both.
Isn't predictability the problem? It seems that many hardware and software attacks, at a very very high level, amount to being too predictable.
What are the proposed benefits of QUIC?
May be misguided, but I feel a little uneasy about bundling TCP functionality, TLS and HTTP into a single protocol over UDP.
May be misguided, but I feel a little uneasy about bundling TCP functionality, TLS and HTTP into a single protocol over UDP.
As a counterpoint to the advantages, the disadvantage is that QUIC is much more expensive on the server side. You loose 25 years of stateless hardware offloads done by the NIC.
Measuring the workload that I care about (Netflix CDN serving static videos), loosing TSO, LRO, and software kTLS, like you would with QUIC, takes a server from serving 90Gb/s @ 62% CPU to serving 35Gb/s and CPU limited. So we'd need essentially 3x as many servers to serve via QUIC as we do to serve via TCP. That has real environmental costs.
And these are old numbers, from servers that don't support hardware kTLS, so the impact of loosing hardware kTLS would make things even worse.
Measuring the workload that I care about (Netflix CDN serving static videos), loosing TSO, LRO, and software kTLS, like you would with QUIC, takes a server from serving 90Gb/s @ 62% CPU to serving 35Gb/s and CPU limited. So we'd need essentially 3x as many servers to serve via QUIC as we do to serve via TCP. That has real environmental costs.
And these are old numbers, from servers that don't support hardware kTLS, so the impact of loosing hardware kTLS would make things even worse.
(I work for Google, opinions my own)
For YouTube, the CPU cost of QUIC is comparable to TCP, though we did spent years optimizing it. [0] has a nice deep dive.
Other CDN vendors like Fastly seem to have the similar experience [1].
I believe sendmmsg combined with UDP GSO (as discussed, for instance, in [2]) has solved most of the problems that were caused by the absence of features like TSO. From what I understand, most of the benefit of TSO comes not from the hardware acceleration, but rather from the fact that it processes multiple packet as one for most of the transmission code path, meaning that all per-packet operations are only invoked once per chunk (as opposed to once per individual IP packet sent).
[0] https://atscaleconference.com/videos/networking-scale-2019-i...
[1] https://www.fastly.com/blog/measuring-quic-vs-tcp-computatio...
[2] https://blog.cloudflare.com/accelerating-udp-packet-transmis...
For YouTube, the CPU cost of QUIC is comparable to TCP, though we did spent years optimizing it. [0] has a nice deep dive.
Other CDN vendors like Fastly seem to have the similar experience [1].
I believe sendmmsg combined with UDP GSO (as discussed, for instance, in [2]) has solved most of the problems that were caused by the absence of features like TSO. From what I understand, most of the benefit of TSO comes not from the hardware acceleration, but rather from the fact that it processes multiple packet as one for most of the transmission code path, meaning that all per-packet operations are only invoked once per chunk (as opposed to once per individual IP packet sent).
[0] https://atscaleconference.com/videos/networking-scale-2019-i...
[1] https://www.fastly.com/blog/measuring-quic-vs-tcp-computatio...
[2] https://blog.cloudflare.com/accelerating-udp-packet-transmis...
> For YouTube
For the CDN/edge this is irrelevant and should not even be part of the discussion. It is obvious it will not change (or will be even better) for them.
The comment you are replying talks exclusively about the "middle boxes". They will have a hardtime with quic, not matter what. (IMHO, a small price to pay, too bad it is something flawed like quic instead of a true distributed solution)
For the CDN/edge this is irrelevant and should not even be part of the discussion. It is obvious it will not change (or will be even better) for them.
The comment you are replying talks exclusively about the "middle boxes". They will have a hardtime with quic, not matter what. (IMHO, a small price to pay, too bad it is something flawed like quic instead of a true distributed solution)
The comment replied to talks about
> Measuring the workload that I care about (Netflix CDN serving static videos)
not middleboxes...
> Measuring the workload that I care about (Netflix CDN serving static videos)
not middleboxes...
GSO is better than nothing, but its still far more expensive than actual hardware TSO that swallows a 64KB send in hardware. At least it was when I did a study of it when I was at Google. This is because it allocates an skb for each MTU sized packet to hold the headers. I think it costs something like 1.5-2.0x real hardware backed TSO, mostly in memory allocation, freeing, and cache misses around header replication.
Also, sendmmsg still touches data, and this has a huge cost. With inline kTLS and sendfile, the CPU never touches data we serve. If nvme drives with big enough controller memory buffers existed, we would not even have to DMA NVME data to host RAM, it could all just be served directly from NVME -> NIC with peer2peer DMA.
Granted, we serve almost entirely static media. I imagine a lot of what YouTube serves is long-tail, and transcoded on demand, and is thus hot in cache. So touching data is not as painful for YouTube as it is for us, since our hot path is already more highly optimized. (eg, our job is easier)
I tried to look at the Networking@Scale link, but I just get a blank page. I wonder if Firefox is blocking something to do with facebook..
Also, sendmmsg still touches data, and this has a huge cost. With inline kTLS and sendfile, the CPU never touches data we serve. If nvme drives with big enough controller memory buffers existed, we would not even have to DMA NVME data to host RAM, it could all just be served directly from NVME -> NIC with peer2peer DMA.
Granted, we serve almost entirely static media. I imagine a lot of what YouTube serves is long-tail, and transcoded on demand, and is thus hot in cache. So touching data is not as painful for YouTube as it is for us, since our hot path is already more highly optimized. (eg, our job is easier)
I tried to look at the Networking@Scale link, but I just get a blank page. I wonder if Firefox is blocking something to do with facebook..
Horses for courses. Is anyone suggesting QUIC for gigantic bulk transfers? TCP isn’t great for latency-sensitive small transfers so we will have QUIC. QUIC will not be perfect for everything, like TCP is not perfect for everything.
> Horses for courses. Is anyone suggesting QUIC for gigantic bulk transfers?
Anyone who's looking to replace HTTP/1.1 and HTTP/2 with HTTP/3? AFAIK QUIC is completely integral to that, in order to avoid this issue you'll need a mixed deployment of HTTP/3 and an older version of the standard.
Anyone who's looking to replace HTTP/1.1 and HTTP/2 with HTTP/3? AFAIK QUIC is completely integral to that, in order to avoid this issue you'll need a mixed deployment of HTTP/3 and an older version of the standard.
I’m positive that an organization the size of Netflix which has dedicated itself absolutely to pushing 200gbps out of every individual box can figure out how to run HTTP 1.1 forever.
I just hope we don't remove support for HTTP/1.1 from our stacks entirely. 2/3 are great for performance but an order of magnitude more complex.
I imagine that HTTP/2 use will almost entirely move to HTTP/3, and HTTP/1.1 usage will decline but there'll still be plenty of it around.
Cloudflare’s Radar dashboard has recent measurements of HTTP/1, 2, and 3 traffic (near the bottom of the page):
https://radar.cloudflare.com/
Right now, HTTP/1.x is 23% of traffic, HTTP/2 is 75%, and HTTP/3 is just 2%. Since this is about overall traffic (visible to Cloudflare), big sites like Google and Facebook dominate. All that HTTP/3 traffic is probably Chrome users watching YouTube.
https://radar.cloudflare.com/
Right now, HTTP/1.x is 23% of traffic, HTTP/2 is 75%, and HTTP/3 is just 2%. Since this is about overall traffic (visible to Cloudflare), big sites like Google and Facebook dominate. All that HTTP/3 traffic is probably Chrome users watching YouTube.
"Whee, the magic number went up, better upgrade".
Despite Google meddling with the standards, "HTTP/3" isn't HTTP.
Despite Google meddling with the standards, "HTTP/3" isn't HTTP.
> Despite Google meddling with the standards
Please let that misconception die. I’m not at all fond of Google, but HTTP/3 is not a Google thing: Google is just one (admittedly significant) party involved in making a thing that lots of parties want and have worked together to make. https://news.ycombinator.com/item?id=25286488 is a relevant comment I wrote a couple of months ago.
Please let that misconception die. I’m not at all fond of Google, but HTTP/3 is not a Google thing: Google is just one (admittedly significant) party involved in making a thing that lots of parties want and have worked together to make. https://news.ycombinator.com/item?id=25286488 is a relevant comment I wrote a couple of months ago.
> ...a thing that lots of parties want and have worked together to make
So,
a) what parties? b) what exactly did they contribute?
Look, yeah, it's a good thing that standards still exist and Google has to play social engineering games instead of suddenly dropping this stuff on us as a fait accompli.
But let's not pretend like Google doesn't own the Internet; it'll save us grief and tears in the future if we see things clearly as they are.
So,
a) what parties? b) what exactly did they contribute?
Look, yeah, it's a good thing that standards still exist and Google has to play social engineering games instead of suddenly dropping this stuff on us as a fait accompli.
But let's not pretend like Google doesn't own the Internet; it'll save us grief and tears in the future if we see things clearly as they are.
It’s all on public record; take a look in the relevant IETF working group. There are quite a large number of parties that have made meaningful contributions, and I’m too lazy to find and enumerate any. And in line with my linked comment, Google engineers want those contributions, as the end result of such collaboration is consistently significantly superior to what was developed by one party alone. Google is not strong-arming IETF into doing things. There’s widespread (though certainly not universal) consensus that QUIC or an equivalent is a worthy goal, and worth collaborating on to achieve that end.
Look, I wanted something like QUIC before they produced it, because HTTP/2 was better than HTTP/1.1 in most ways, but had the critical TCP HOLB problem that makes it markedly worse than HTTP/1.1 in some situations—and something like QUIC is the only way of fixing that, since the SCTP approach is no longer socially viable. (And before that, I had long wanted something like HTTP/2, because the limitations of HTTP/1.1 were sometimes rather frustrating. —Though I must confess that I wasn’t immediately taken with SPDY and the particular way Google pushed it initially.)
Google doesn’t own the internet. Let it go. Yes, they have an unhealthily large influence on consumer matters—but also nowhere near as large in infrastructural. Google were the ones to advance the initial SPDY and QUIC proposals because their position as massive server operators and manufacturers of a popular browser meant that they were simply the company best-suited to making such initial development (and sure, it served their interests well too).
Look, I wanted something like QUIC before they produced it, because HTTP/2 was better than HTTP/1.1 in most ways, but had the critical TCP HOLB problem that makes it markedly worse than HTTP/1.1 in some situations—and something like QUIC is the only way of fixing that, since the SCTP approach is no longer socially viable. (And before that, I had long wanted something like HTTP/2, because the limitations of HTTP/1.1 were sometimes rather frustrating. —Though I must confess that I wasn’t immediately taken with SPDY and the particular way Google pushed it initially.)
Google doesn’t own the internet. Let it go. Yes, they have an unhealthily large influence on consumer matters—but also nowhere near as large in infrastructural. Google were the ones to advance the initial SPDY and QUIC proposals because their position as massive server operators and manufacturers of a popular browser meant that they were simply the company best-suited to making such initial development (and sure, it served their interests well too).
I'm pretty sure YouTube uses QUIC for video streaming today, which is a similar workload to ours.
I think that indicates more about the economics of YouTube than anything. Probably their frontend CPU costs would have to go up by a factor of ten thousand before it even began to approach their costs for compression and storage of user uploads.
> I'm pretty sure YouTube uses QUIC for video streaming today
Is there any media transfer protocol based on QUIC?
Is there any media transfer protocol based on QUIC?
Lucas Pardue, who is the IETF QUIC WG chair, has a great talk from Mux's Demuxed conf last year on using QUIC as a transport for UDP streaming: https://www.youtube.com/watch?v=Zdkjd7-EWmQ&feature=emb_titl...
This is not dissimilar from SRT.
This is not dissimilar from SRT.
I found an article from 4 years ago saying that 20% of youtube's traffic was QUIC: https://www.fiercewireless.com/wireless/youtube-driving-more...
Youtube is delivering video over HTTP. HTTP3, i.e. it is transported over QUIC.
Yep: YouTube currently delivers over gQUIC and h3 (IETF QUIC).
We advertise the following alt-svc for most devices:
> h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
HTTP/3 (over IETF QUIC) is still not as widely deployed due to lesser client support, but that's growing as both Chrome[1], Firefox and Apple (in iOS Safari, when enabled) adopt it and the latest drafts.
[1]: https://blog.chromium.org/2020/10/chrome-is-deploying-http3-...
We advertise the following alt-svc for most devices:
> h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
HTTP/3 (over IETF QUIC) is still not as widely deployed due to lesser client support, but that's growing as both Chrome[1], Firefox and Apple (in iOS Safari, when enabled) adopt it and the latest drafts.
[1]: https://blog.chromium.org/2020/10/chrome-is-deploying-http3-...
Interesting. Could this be mitigated at all with QUIC hardware?
It seems like if the tradeoffs are this bad at scale Google wouldn't be pushing QUIC.
It seems like if the tradeoffs are this bad at scale Google wouldn't be pushing QUIC.
It can be mitigated, and companies are working on it. However, there is no NIC offering hardware QUIC protocol offload that I'm currently aware of. Part of what makes it challenging is one of the features of QUIC: That the protocol headers are themselves encrypted.
But do the headers have much to do with power efficiency? Seems like that would mostly hinge on encryption and state machine efficiency.
They have to do with the viability of offloading. You can't give the NIC an encrypted stream and have it handle the protocol stuff if it needs to put things inside the encryption to do so.
The Intel 700 and 800 series NICs have a DDP for QUIC.
Most applications on the internet are CRUD apps and not everyone is serving Netflix CDN data. TCP hasn't really changed much in the past 25 years due to routers on the internet being strict about its standards. Just look at 'TCP Fast Open', while it was supposed to drastically cut down on connection time in TCP, it can't be used on the internet due to routers behaving erratically. Apple tried it in production and then reverted it.
Since QUIC is based on UDP, it doesn't face the same limitations that TCP does. TCP also suffers from head of line blocking, which QUIC also eliminates. It is also more secure due to header being encrypted, unlike TCP. Plus you also get multiplexing built-in. QUIC is far better than TCP and for serving websites & APIs, it is a much better alternative.
Since QUIC is based on UDP, it doesn't face the same limitations that TCP does. TCP also suffers from head of line blocking, which QUIC also eliminates. It is also more secure due to header being encrypted, unlike TCP. Plus you also get multiplexing built-in. QUIC is far better than TCP and for serving websites & APIs, it is a much better alternative.
But CRUDs also benefit from load balancing that is going to be much more expensive without hardware support.
For the other problems, mostly satisfactory solutions exist.
> So we'd need essentially 3x as many servers to serve via QUIC as we do to serve via TCP. That has real environmental costs.
So do ads, and no government seems to care much.
So do ads, and no government seems to care much.
Because other things with environmental cost (which are widely criticized for it!) exist, one shouldn't consider environmental costs?
3x as many servers, it is probably going to be 3x more expensive. Money is something that everyone cares about
Such false equivalence. Everything costs resources to produce. Simply stating that it costs resources, or even just stating how much resources it costs, is completely meaningless on its own.
Pixar movies cost resources, prolonging life with medical treatment costs resources, chocolate candy bars cost resources, operating the Olympic Games costs resources.
In each case, various people believe the resource costs are worth it to get the thing that is produced. Same for bitcoin, same for ads.
You can’t just say they cost resources. If you’re advocating these things shouldn’t exist, you either need to get into the specifics of why they offer value but just not enough to offset their resource costs, or why they don’t offer value, and persuade others to agree with you.
Judging by the success of ads and bitcoin, I think, “these things consume resources” is a pretty weak and useless argument. It would not matter if the resource costs were astronomical or tiny, it’s a specious chain of reasoning in principle.
Pixar movies cost resources, prolonging life with medical treatment costs resources, chocolate candy bars cost resources, operating the Olympic Games costs resources.
In each case, various people believe the resource costs are worth it to get the thing that is produced. Same for bitcoin, same for ads.
You can’t just say they cost resources. If you’re advocating these things shouldn’t exist, you either need to get into the specifics of why they offer value but just not enough to offset their resource costs, or why they don’t offer value, and persuade others to agree with you.
Judging by the success of ads and bitcoin, I think, “these things consume resources” is a pretty weak and useless argument. It would not matter if the resource costs were astronomical or tiny, it’s a specious chain of reasoning in principle.
How many of these downsides are inherent to the protocol compared to simply not being optimized yet? I get that a QUIC optimized NIC is unlikely to be right around the corner (these things take time), but is there anything that makes such a thing impossible?
Not a big fan of QUIC (for other reasons) but I didn't consider your very valid points. Not be able to utilize TCP offload engines is another big disadvante of QUIC - but to be fair, I think we will see QUIC offload engines develop over time just as they did with TCP. Maybe those Intel/Altera or AMD/Xilinx deals will pay of for datacenter, for exactly those reasons (quick adaption of emerging network protocols by programming offload engines to FPGAs).
> You loose 25 years of stateless hardware offloads done by the NIC.
That's a feature.
Otherwise the industry will die off slowly. Case in point, OpenStack first, and later kubernetes, were exactly this kind of innovation. It offers very tiny benefit and a whole slew of plugging points for the industry players to hook upon; but is beneficial enough for mostly everyone to be comfortably endorse a piece of technology that at the time were already starting to decaying... Of course in this case, OpenStack has been a much worse tech because of it was developed by people haven't been the mainstream...
That's a feature.
Otherwise the industry will die off slowly. Case in point, OpenStack first, and later kubernetes, were exactly this kind of innovation. It offers very tiny benefit and a whole slew of plugging points for the industry players to hook upon; but is beneficial enough for mostly everyone to be comfortably endorse a piece of technology that at the time were already starting to decaying... Of course in this case, OpenStack has been a much worse tech because of it was developed by people haven't been the mainstream...
From my understanding it's mostly head-of-the-line blocking.
HTTP/2 was introduced to solve head-of-the-line blocking on the application level (one HTTP/1.1 connection could only handle one request at the time, barring poorly supported pipelining)
TCP itself also only allows one stream of data to flow at the time (in each direction) - in case of poor network quality you are going to lose some TCP segments, and if you fill in the receiver's window, the transfer might halt until retransmission succeeds (this includes ALL streams within HTTP/2). Using UDP allows you to circumvent that.
HTTP/2 was introduced to solve head-of-the-line blocking on the application level (one HTTP/1.1 connection could only handle one request at the time, barring poorly supported pipelining)
TCP itself also only allows one stream of data to flow at the time (in each direction) - in case of poor network quality you are going to lose some TCP segments, and if you fill in the receiver's window, the transfer might halt until retransmission succeeds (this includes ALL streams within HTTP/2). Using UDP allows you to circumvent that.
I've wondered about this. It makes sense in theory, but it seems like if you have data loss on one channel and need retransmission, you probably also have data loss on other channels so they'll end up waiting for their own retransmissions anyway. It seems more like an inherent issue with building reliable streams on an unreliable channel.
I'm sure there's hard research on it. Anyone know some good papers?
I'm sure there's hard research on it. Anyone know some good papers?
This one seems pretty thorough: https://upcommons.upc.edu/bitstream/handle/2117/169283/TJM1d... (Chapter 5).
There's also a bunch from Google at various stages of QUIC development.
There's also a bunch from Google at various stages of QUIC development.
Here's a comparison of HTTP2 vs HTTP3 (QUIC) from Cloudflare:
https://blog.cloudflare.com/http-3-vs-http-2/
https://blog.cloudflare.com/http-3-vs-http-2/
Proper stream multiplexing, working connection migration on IP changes, faster connection setup for the common case with 0-RTT, solving the TCP ossification issues by decoupling protocol upgrades from OS upgrades and by preventing middleboxes from messing up flows when new options are introduced.
> working connection migration on IP changes
MPTCP is available in iOS and recent linux kernels. So you don't need QUIC for that.
> decoupling protocol upgrades from OS upgrades
This is as much a downside as it is an upside. Now you have to potentially juggle hundreds of applications each shipping their own transport protocol implementation. And maybe their own DNS client too.
MPTCP is available in iOS and recent linux kernels. So you don't need QUIC for that.
> decoupling protocol upgrades from OS upgrades
This is as much a downside as it is an upside. Now you have to potentially juggle hundreds of applications each shipping their own transport protocol implementation. And maybe their own DNS client too.
Dynamic linking has lost. Static linking fully self-contained binaries / containers etc combined with robust, deterministic build automation is the future.
I do think that in many situations dynamic linking doesn't make a whole lot of sense these days (like, say, a JPEG decoding library for instance). But having a central point where you can configure, test and administer networking makes a lot of sense to me.
The idea of every application coming up with its own DNS implementation for instance annoys me greatly. I can already anticipate the amount of time I'm going to lose hunting down the way application X handles DNS because it won't apply my system-wide settings.
I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest.
Moving stuff to higher layers is, IMO, mainly because Google wants to become the new Microsoft/Apple and moving that stuff up is a way to take the control away from Windows/Mac OS. The browser is the OS. You use web apps instead of apps.
You turn every device out there into a glorified ChromeBook.
The idea of every application coming up with its own DNS implementation for instance annoys me greatly. I can already anticipate the amount of time I'm going to lose hunting down the way application X handles DNS because it won't apply my system-wide settings.
I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest.
Moving stuff to higher layers is, IMO, mainly because Google wants to become the new Microsoft/Apple and moving that stuff up is a way to take the control away from Windows/Mac OS. The browser is the OS. You use web apps instead of apps.
You turn every device out there into a glorified ChromeBook.
> I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest.
IBM z/OS actually does this with a feature called AT-TLS (Application Transparent TLS) [0]. You don't even need to call setsockopt (actually z/OS uses ioctl instead of setsockopt for this, but same idea). You can turn a non-TLS service into a TLS service simply by modifying the OS configuration.
[0] https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/...
IBM z/OS actually does this with a feature called AT-TLS (Application Transparent TLS) [0]. You don't even need to call setsockopt (actually z/OS uses ioctl instead of setsockopt for this, but same idea). You can turn a non-TLS service into a TLS service simply by modifying the OS configuration.
[0] https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/...
People have built (more than once even) the same functionality for the Linux and NT kernels.
https://www.kernel.org/doc/html/latest/networking/tls.html
https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-1...
https://docs.microsoft.com/en-us/windows/win32/http/kernel-m...
https://www.kernel.org/doc/html/latest/networking/tls.html
https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-1...
https://docs.microsoft.com/en-us/windows/win32/http/kernel-m...
That isn't the same functionality.
- Linux kernel TLS doesn't provide a full implementation of TLS in the Linux kernel, only the symmetric encryption part. The handshake still has to be performed by the application in user space, and the application then needs to call setsockopt() in order to inject the keys into the kernel. By contrast, z/OS AT-TLS implements all of TLS (including the handshake), so the application doesn't have to do anything. As far as the application is concerned, a TLS socket looks exactly the same as a plain one (unless the application starts calling the AT-TLS ioctl, which will tell it whether a socket is plain or TLS)
- The Windows "kernel mode SSL" is only for the built-in HTTP server. It doesn't apply to clients, or to other protocols than HTTP. By contrast, z/OS AT-TLS works for any protocol, not just HTTP, and supports both clients and servers
So nobody has built the same functionality as z/OS AT-TLS in Linux or Windows. People have built some small subsets of z/OS AT-TLS's functionality, but not the generality that AT-TLS provides.
- Linux kernel TLS doesn't provide a full implementation of TLS in the Linux kernel, only the symmetric encryption part. The handshake still has to be performed by the application in user space, and the application then needs to call setsockopt() in order to inject the keys into the kernel. By contrast, z/OS AT-TLS implements all of TLS (including the handshake), so the application doesn't have to do anything. As far as the application is concerned, a TLS socket looks exactly the same as a plain one (unless the application starts calling the AT-TLS ioctl, which will tell it whether a socket is plain or TLS)
- The Windows "kernel mode SSL" is only for the built-in HTTP server. It doesn't apply to clients, or to other protocols than HTTP. By contrast, z/OS AT-TLS works for any protocol, not just HTTP, and supports both clients and servers
So nobody has built the same functionality as z/OS AT-TLS in Linux or Windows. People have built some small subsets of z/OS AT-TLS's functionality, but not the generality that AT-TLS provides.
Fair, although I think 99.9% of the value is in the trick Linux is doing here. The handshake is at once the most complicated part (which means you don't really want it in Ring Zero) and the part you're most likely to want to customise (e.g. OCSP stapling is in the handshake, certificate compression is in the handshake, SNI handling is in the handshake, and so on) which means that's the part an application author is least likely to be satisfied with being done on their behalf.
Notice that in Linux because sockets "are" file descriptors you actually can put all connection and handshake work into a separate processes altogether, and just pass the socket (now TLS encrypted) to a process that pumps data back and forth, without it needing to be aware of TLS at all.
Notice that in Linux because sockets "are" file descriptors you actually can put all connection and handshake work into a separate processes altogether, and just pass the socket (now TLS encrypted) to a process that pumps data back and forth, without it needing to be aware of TLS at all.
> Fair, although I think 99.9% of the value is in the trick Linux is doing here
For z/OS AT-TLS, the primary use case is that I can take a legacy app which knows nothing about TLS, and make it support TLS with zero code changes. You create policy rules in the OS configuration, they resemble firewall rules (they can match on source and destination address, port and process name), and if an application's socket call matches the rule, the plain socket gets transparently swapped with a TLS one.
Linux kernel TLS is trying to address a completely different use case: I have an app which knows all about TLS and already has the code (most likely via some shared library such as OpenSSL) to do it all by itself, but I'm going to modify it to move some of the processing to kernel space for improved performance.
What @simias was asking for, "I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest" isn't exactly either use case, but it is closer to z/OS AT-TLS use case than Linux kTLS use case. Indeed, AT-TLS supports a mode of operation in which, rather than configuring TLS to be automatically applied by rules, it is manually requested by the app calling an ioctl on the socket - but, all the TLS configuration like which certificates to trust is pulled from the OS configuration - that seems like almost exactly what @simias was requesting.
> The handshake is at once the most complicated part (which means you don't really want it in Ring Zero)
I don't have a lot of insight into how AT-TLS is implemented internally, but I know some parts of it run in user space (inside a daemon called "pagent"). Having TLS implemented in the operating system doesn't necessarily mean it has to be implemented in the kernel. Some operating systems (e.g. Windows NT) say that the system call interface is private and the public interface is a library call. If an OS goes with that model, then the OS-supplied TLS implementation could be in a shared library not inside the kernel. Of course, that isn't the model Linux went with, it made system calls a public interface and so even if you put an AT-TLS-style transparent TLS implementation in the C library, some apps would bypass it by using system calls directly.
That isn't necessarily problematic. Actually, z/OS AT-TLS gets bypassed by some apps too. z/OS, being an operating system with decades of legacy, actually has multiple sockets APIs, and AT-TLS doesn't hook them all (whether due to technical limitations or simply IBM didn't decide it was worthwhile spending resources on.) In particular, the so-called "Pascal sockets API" (I believe it is called that because originally it was written in Pascal, and designed for use by Pascal code, but programs written in other languages such as C or COBOL or assembler can call it) doesn't go through AT-TLS. Likewise, apps that use the UNIX SystemV STREAMS API don't work with AT-TLS either. However, only a minority of z/OS apps use either of those legacy sockets APIs, and using those APIs is discouraged for new code. So, somewhat like z/OS does, if someone wanted to add this feature to Linux, they could always put it in the C library, and if an app bypassed that, well "sorry you don't get the transparent TLS feature".
Another option would be to do something like FUSE – have a daemon in user-space which does the TLS handshake. Inside the connect() or accept() system calls, the kernel could send the socket to that daemon, get it to do the TLS handshake, and then return the syscall when the daemon says it is done. All doable, the only real questions are (1) is anyone sufficiently motivated to add this feature to Linux (quite possibly not); (2) if they implement it, will the Linux kernel devs accept it (don't know about that either)
For z/OS AT-TLS, the primary use case is that I can take a legacy app which knows nothing about TLS, and make it support TLS with zero code changes. You create policy rules in the OS configuration, they resemble firewall rules (they can match on source and destination address, port and process name), and if an application's socket call matches the rule, the plain socket gets transparently swapped with a TLS one.
Linux kernel TLS is trying to address a completely different use case: I have an app which knows all about TLS and already has the code (most likely via some shared library such as OpenSSL) to do it all by itself, but I'm going to modify it to move some of the processing to kernel space for improved performance.
What @simias was asking for, "I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest" isn't exactly either use case, but it is closer to z/OS AT-TLS use case than Linux kTLS use case. Indeed, AT-TLS supports a mode of operation in which, rather than configuring TLS to be automatically applied by rules, it is manually requested by the app calling an ioctl on the socket - but, all the TLS configuration like which certificates to trust is pulled from the OS configuration - that seems like almost exactly what @simias was requesting.
> The handshake is at once the most complicated part (which means you don't really want it in Ring Zero)
I don't have a lot of insight into how AT-TLS is implemented internally, but I know some parts of it run in user space (inside a daemon called "pagent"). Having TLS implemented in the operating system doesn't necessarily mean it has to be implemented in the kernel. Some operating systems (e.g. Windows NT) say that the system call interface is private and the public interface is a library call. If an OS goes with that model, then the OS-supplied TLS implementation could be in a shared library not inside the kernel. Of course, that isn't the model Linux went with, it made system calls a public interface and so even if you put an AT-TLS-style transparent TLS implementation in the C library, some apps would bypass it by using system calls directly.
That isn't necessarily problematic. Actually, z/OS AT-TLS gets bypassed by some apps too. z/OS, being an operating system with decades of legacy, actually has multiple sockets APIs, and AT-TLS doesn't hook them all (whether due to technical limitations or simply IBM didn't decide it was worthwhile spending resources on.) In particular, the so-called "Pascal sockets API" (I believe it is called that because originally it was written in Pascal, and designed for use by Pascal code, but programs written in other languages such as C or COBOL or assembler can call it) doesn't go through AT-TLS. Likewise, apps that use the UNIX SystemV STREAMS API don't work with AT-TLS either. However, only a minority of z/OS apps use either of those legacy sockets APIs, and using those APIs is discouraged for new code. So, somewhat like z/OS does, if someone wanted to add this feature to Linux, they could always put it in the C library, and if an app bypassed that, well "sorry you don't get the transparent TLS feature".
Another option would be to do something like FUSE – have a daemon in user-space which does the TLS handshake. Inside the connect() or accept() system calls, the kernel could send the socket to that daemon, get it to do the TLS handshake, and then return the syscall when the daemon says it is done. All doable, the only real questions are (1) is anyone sufficiently motivated to add this feature to Linux (quite possibly not); (2) if they implement it, will the Linux kernel devs accept it (don't know about that either)
Not to bring up the usual debate again, but anyone trying to sell you one side of the static/dynamic debate without acknowledging that this is not a cut-and-dry issue is doing you a disservice and it is probably in your best interest to not listen to them.
> solving the TCP ossification issues by decoupling protocol upgrades from OS upgrades
QUIC explicitly addresses "network middlebox ossification" of TCP, by encrypting almost everything about the protocol. This type of ossification is where the network blocks or corrupts any deviations that it doesn't recognise but thinks it does.
TCP "OS ossification" is a different kind. By itself, this could have been overcome by streaming TCP-in-UDP and amending it from there. Even that is only because of OS APIs. If OSes allowed applications to bind to a TCP port and process the raw packets, applications that want to could implement TCP themselves.
If that kind of dual-binding seems strange, I think it's actually more or less what we'll end up with with QUIC in the end: The OS providing QUIC sockets (socket(AF_INET,SOCK_QUIC,...)) to applications that don't care to implement the QUIC stack themselves, while allowing other applications to bind to UDP in the usual way and implement their own application-level QUIC.
I think current QUIC solves application vs. OS ossification issues in the short term, allowing things to evolve beyond TCP, but it's a temporary benefit.
In time I think we will see QUIC ossify when it's implemented in many applications that don't get updated.
Most browsers are updated often. But I'm seeing more obscure applications starting to include QUIC and depend on it (without any TCP fallback even) - leading eventually to hundreds of "hand-written quality" QUIC implementations, all destined to get out of date. Various languages are implementing their own QUIC libraries, and these aren't all going to be maintained the same way. Shipped applications ossify too.
That's why I think it'll end up in the OS kernels eventually.
QUIC explicitly addresses "network middlebox ossification" of TCP, by encrypting almost everything about the protocol. This type of ossification is where the network blocks or corrupts any deviations that it doesn't recognise but thinks it does.
TCP "OS ossification" is a different kind. By itself, this could have been overcome by streaming TCP-in-UDP and amending it from there. Even that is only because of OS APIs. If OSes allowed applications to bind to a TCP port and process the raw packets, applications that want to could implement TCP themselves.
If that kind of dual-binding seems strange, I think it's actually more or less what we'll end up with with QUIC in the end: The OS providing QUIC sockets (socket(AF_INET,SOCK_QUIC,...)) to applications that don't care to implement the QUIC stack themselves, while allowing other applications to bind to UDP in the usual way and implement their own application-level QUIC.
I think current QUIC solves application vs. OS ossification issues in the short term, allowing things to evolve beyond TCP, but it's a temporary benefit.
In time I think we will see QUIC ossify when it's implemented in many applications that don't get updated.
Most browsers are updated often. But I'm seeing more obscure applications starting to include QUIC and depend on it (without any TCP fallback even) - leading eventually to hundreds of "hand-written quality" QUIC implementations, all destined to get out of date. Various languages are implementing their own QUIC libraries, and these aren't all going to be maintained the same way. Shipped applications ossify too.
That's why I think it'll end up in the OS kernels eventually.
You're right that the two forms of ossification are distinct, but I'm quite certain that both were driving factors here. Rolling out new TCP options is a decade-long process, and if anything goes wrong with the initial design, once it is shipping you're basically never fixing it. Applications are much easier to update than operating systems, auto-update for the vast majority of users, and for the <1% who don't update the app can always fall back to TCP.
(E.g. the rationale for TOU, now-dead Facebook's UDP-based transport explicitly stated userspace-only deployability as requirement. They needed a solution for all their other requirements to be deployed in 2015, not with a consensus design approved in 2020 and in wide deployement in 2025.)
The middle-box driven ossification happened by making things harder. The OS upgrade driven ossification happened by reducing/delaying the payoff.
(E.g. the rationale for TOU, now-dead Facebook's UDP-based transport explicitly stated userspace-only deployability as requirement. They needed a solution for all their other requirements to be deployed in 2015, not with a consensus design approved in 2020 and in wide deployement in 2025.)
The middle-box driven ossification happened by making things harder. The OS upgrade driven ossification happened by reducing/delaying the payoff.
QUIC is TCP+TLS. HTTP is done as a separate layer on top.
The benefits are: future protocol evolution (TCP is extremely difficult to change because of middleboxes, QUIC encrypts almost all of the header to stop middleboxes from messing things up) faster connection establishment (fewer RTTs thanks to bundling TCP+TLS handshakes), no head-of-line blocking when sending multiply streams over a single connection.
The benefits are: future protocol evolution (TCP is extremely difficult to change because of middleboxes, QUIC encrypts almost all of the header to stop middleboxes from messing things up) faster connection establishment (fewer RTTs thanks to bundling TCP+TLS handshakes), no head-of-line blocking when sending multiply streams over a single connection.
QUIC is more similar to UDP+SCTP+TLS. Or, if you skip UDP and directly layer it over IP, to SCTP+TLS.
Is this sustainable though? Won't the middle boxes adapt?
It's designed with almost everything encrypted so that middleboxes can't inspect the contents of packets and filter or change them. This is essential, as it's been found that middleboxes now break almost every kind of experimental protocol that's not shielded in this way. So it's designed very much to resist ossification and allow protocol evolution.
Still, some vendors are adapting to QUIC by blocking QUIC:
https://www.fastvue.co/fastvue/blog/googles-quic-protocols-s...
Still, some vendors are adapting to QUIC by blocking QUIC:
https://www.fastvue.co/fastvue/blog/googles-quic-protocols-s...
Resolving the QUIC issue
The good news is that if QUIC communication does not work between a client and a server, the traffic will fall back to traditional HTTP/HTTPS over TCP, where it can be inspected, controlled, logged and reported on as usual.
At the time of writing, the advice from most firewall vendors is to block QUIC until support is officially added to their products. This recommended method will vary from firewall to firewall. Some firewalls allow QUIC by default while others block it by default, but all firewalls are able to allow or block it.
Almost nothing is plaintext so iterations can be done within the encrypted layer. Iterations could start being done at the same speed that http is done today.
Middleboxes by design MITM connections. They'll terminate the connection from the client and the server, unencrypt and reencrypt as necessary.
That's the whole point of the troublesome middleboxes. They're not passive listeners. They're active participants, with fragile implementations.
That's the whole point of the troublesome middleboxes. They're not passive listeners. They're active participants, with fragile implementations.
> Middleboxes by design MITM connections.
If only this was true. Almost all of TLS 1.3 would be more straight forward if you were right. As a trivial example, clients could begin by saying they want to speak TLS 1.3 rather than pretending they want TLS 1.2 even though they actually don't.
Implementing a security device as back-to-back proxy in which there are two connections, one from a client to the device, then another from the device to the server, would be entirely compliant with the standard, it would trivially enable forward compatibility, and it would make it easier to reason about the provided security features (if any).
But it would make them (much) more expensive.
The true purpose of such middleboxes is not security, it is to transfer money from gullible customers to the vendor. "Security" is just an excuse, if they thought you'd buy it to prevent COVID-19 that's what they would claim it does.
So, a common trick went like this: When a client makes an HTTPS connection, you let it ride, but you passively watch the first few packets they receive. You're looking for the X.509 certificate from the server, which you will then inspect to figure out if it's somebody you trust. If not, you reset the connection and next time they try you intercept, perhaps to display a "Warning: Unauthorized Terror Porn Gay Propaganda Web Site. Your Boss Has Been Notified" message.
Notice this doesn't actually provide any security at all, X.509 certificates are public documents, my servers can give you the certificate for Google, or a local hospital, or PornHub, even though I am not in fact Google, a local hospital or PornHub. The middlebox won't know this was bogus because the protocol only proves the server knows the keys for this certificate to the client not a third party eavesdropping.
But this "trick" does break TLS 1.3 as originally designed because since a plaintext X.509 certificate is only useful for snooping and provides no security benefit it is now encrypted, and these middleboxes would freak out.
So what was done about that? Well they don't actually provide any security so we just sidestepped it. TLS 1.3 claims to be a TLS 1.2 resumption. "Oh you were already talking to this server about something else. I'm sure I must have checked that time and it was fine. On you go" says the middlebox.
This worked very well for their actual purpose, as you can see from the revenues of middlebox suppliers.
If only this was true. Almost all of TLS 1.3 would be more straight forward if you were right. As a trivial example, clients could begin by saying they want to speak TLS 1.3 rather than pretending they want TLS 1.2 even though they actually don't.
Implementing a security device as back-to-back proxy in which there are two connections, one from a client to the device, then another from the device to the server, would be entirely compliant with the standard, it would trivially enable forward compatibility, and it would make it easier to reason about the provided security features (if any).
But it would make them (much) more expensive.
The true purpose of such middleboxes is not security, it is to transfer money from gullible customers to the vendor. "Security" is just an excuse, if they thought you'd buy it to prevent COVID-19 that's what they would claim it does.
So, a common trick went like this: When a client makes an HTTPS connection, you let it ride, but you passively watch the first few packets they receive. You're looking for the X.509 certificate from the server, which you will then inspect to figure out if it's somebody you trust. If not, you reset the connection and next time they try you intercept, perhaps to display a "Warning: Unauthorized Terror Porn Gay Propaganda Web Site. Your Boss Has Been Notified" message.
Notice this doesn't actually provide any security at all, X.509 certificates are public documents, my servers can give you the certificate for Google, or a local hospital, or PornHub, even though I am not in fact Google, a local hospital or PornHub. The middlebox won't know this was bogus because the protocol only proves the server knows the keys for this certificate to the client not a third party eavesdropping.
But this "trick" does break TLS 1.3 as originally designed because since a plaintext X.509 certificate is only useful for snooping and provides no security benefit it is now encrypted, and these middleboxes would freak out.
So what was done about that? Well they don't actually provide any security so we just sidestepped it. TLS 1.3 claims to be a TLS 1.2 resumption. "Oh you were already talking to this server about something else. I'm sure I must have checked that time and it was fine. On you go" says the middlebox.
This worked very well for their actual purpose, as you can see from the revenues of middlebox suppliers.
No, "middleboxes" does not just refer to MITM proxies, but a whole slew of things (many of which are broken in various different ways).
One does not simply “unencrypt” traffic, though. That’s the whole point of TLS.
Indeed, one intercepts and terminates the TCP (or now UDP) session. No version of TLS is immune to these middleboxes.
I suspect I'm being misunderstood. I don't intend to suggest these pasky middleboxes spring up randomly on the Internet and anyone is at risk. These are deliberately installed on the edge of corporate networks, and their sole purpose is to intercept, unencrypt and filter traffic.
There's no technological solution for a middleware box that emulates a client to servers, and emulates a server to clients, and is operating exactly as designed.
This shouldn't be new or surprising or groundbreaking to anyone. It's just a fancy name for a poorly implemented proxy.
I suspect I'm being misunderstood. I don't intend to suggest these pasky middleboxes spring up randomly on the Internet and anyone is at risk. These are deliberately installed on the edge of corporate networks, and their sole purpose is to intercept, unencrypt and filter traffic.
There's no technological solution for a middleware box that emulates a client to servers, and emulates a server to clients, and is operating exactly as designed.
This shouldn't be new or surprising or groundbreaking to anyone. It's just a fancy name for a poorly implemented proxy.
Default configurations – without tampering by corporate admins – are of course immune.
Application layer developers are fighting corporate TLS interception with things like certificate pinning, not using the OS certificate store, making it harder to modify the app's certificate store. The goal is to heavily discourage corporations from breaking end-to-end security to spy on their employees.
Application layer developers are fighting corporate TLS interception with things like certificate pinning, not using the OS certificate store, making it harder to modify the app's certificate store. The goal is to heavily discourage corporations from breaking end-to-end security to spy on their employees.
It is relatively easy to override certificate pins by modifying the browser that's installed on the corporate network.
In those places where they are adding a "trusted" local middlebox CA to the client for interception, modifying the browser's pin store (or its logic) is not such a big stretch on top of that.
At least other devices, such as users own devices on the corporate network, are immune to this.
In those places where they are adding a "trusted" local middlebox CA to the client for interception, modifying the browser's pin store (or its logic) is not such a big stretch on top of that.
At least other devices, such as users own devices on the corporate network, are immune to this.
Expect middleboxes to aggressively block QUIC and similar harmful adtech products designed to circumvent inspection and security.
Most of QUIC is already supported by SCTP, which could have made IPv6 an even more attractive proposition because the reason SCTP has been poorly adopted is because of the number of middleboxes, mostly for NAT.
There were a few experimental HTTP/2 over SCTP implementations. It worked pretty well.
But since the current NAT infested Internet requires smuggling SCTP over UDP anyway you may as well go all out and use QUIC which collapses the various protocol layers into a single, more efficient protocol.
But since the current NAT infested Internet requires smuggling SCTP over UDP anyway you may as well go all out and use QUIC which collapses the various protocol layers into a single, more efficient protocol.
0rtt handshake (or 1rtt for new connections) and stream multiplexing (no head of line blocking) come to my mind.
Oh, and connection migration (wifi to cell), but that's a bit more tricky.
Oh, and connection migration (wifi to cell), but that's a bit more tricky.
Is it still true that QUIC avoids inspection/filtering, so it's blocked by a lot of corporate firewalls?
Since it's a new protocol, they will probably err on the side of blocking it until they figure out how to MITM it.
(Recently had to deal with a client who said nothing about MITMing our HTTPS, and a coworker who then installed a root cert for them anyway... really pissed me off.)
(Recently had to deal with a client who said nothing about MITMing our HTTPS, and a coworker who then installed a root cert for them anyway... really pissed me off.)
It's UDP which is generally blocked
Anything other than a pipenet will be fingerprintable at some level. A pipenet is a network in which all links run at constant utilization, with dummy traffic (indistinguishable from useful traffic) sent over the links during idle periods. Pipenets are of course inefficient, but everything else is going to reveal some kind of signal distinguishable from noise at some level.
Since I have broadband, it would be nice to set aside a couple percent of my bandwidth for a pipenet (maybe over Tor, as well) and then leave the rest for low-security stuff.
That way I have a place for high-security low-bandwidth text to go if I ever need it.
That way I have a place for high-security low-bandwidth text to go if I ever need it.
It is a shame that Tor itself doesn't have pipenet features.
At least some of this document is based on much older versions of QUIC. In particular it mentions RST_STREAM which went away by the end of 2018 in favour of RESET_STREAM.
In fact it's possible it isn't even talking about the proposed IETF protocol QUIC at all, but instead Google's QUIC ("gQUIC" in modern parlance) in which case this might as well be a paper saying the iPhone is vulnerable to an attack but it turns out it means a 1980s device named "iPhone" not the Apple product.
It certainly references a bunch of gQUIC papers, which could mean that's blind references from a hasty Google search by researchers who don't read their own references - but equally could mean they really did do this work on gQUIC.
In fact it's possible it isn't even talking about the proposed IETF protocol QUIC at all, but instead Google's QUIC ("gQUIC" in modern parlance) in which case this might as well be a paper saying the iPhone is vulnerable to an attack but it turns out it means a 1980s device named "iPhone" not the Apple product.
It certainly references a bunch of gQUIC papers, which could mean that's blind references from a hasty Google search by researchers who don't read their own references - but equally could mean they really did do this work on gQUIC.
As you know from carefully reading the paper, it states that they cloned the sites with HTrack and served them on their LAN with "Caddy Server2". Perhaps then we could guess that the version of QUIC they tested is the version of QUIC that Caddy is using: https://github.com/lucas-clemente/quic-go (v0.19.3)
> in which case this might as well be a paper saying the iPhone is vulnerable to an attack but it turns out it means a 1980s device named "iPhone" not the Apple product.
More like it means the iPhone X instead of the newer iPhone 11
More like it means the iPhone X instead of the newer iPhone 11
A more accurate analogy based on the relationship between gQUIC and IETF QUIC would be that an early non-released version of the iPhone is vulnerable to an attack.
Do any user agents still use gquic? People still use old phones but pretty rarely old versions of chrome.
Current versions of Chrome still use gQUIC for most instances when talking with gQUIC-capable servers such as Google and Youtube.
Just checked, mine used version Q050 just now.
Of course, there are many versions of gQUIC, some more like IETF QUIC than others as they are transitioning parts of the protocol in stages. Version Q050 is the pre-TLS version.
As it's used between Chrome and Youtube, a lot of the world's internet traffic is over gQUIC at the moment.
Just checked, mine used version Q050 just now.
Of course, there are many versions of gQUIC, some more like IETF QUIC than others as they are transitioning parts of the protocol in stages. Version Q050 is the pre-TLS version.
As it's used between Chrome and Youtube, a lot of the world's internet traffic is over gQUIC at the moment.
Pretty sure Chromium/Chrome/derivatives still support gQUIC.
There hasn't been any Intent to Remove, and it was mentioned in https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYL..., so yes I think it still supported.
On the other hand, since this set of vulnerabilities seems to be about passive fingerprinting by intermediaries, what actually matters is how much traffic is still running gquic, right? And I think most servers have moved over to HTTP/3?
(Disclosure: I work for Google, speaking only for myself)
On the other hand, since this set of vulnerabilities seems to be about passive fingerprinting by intermediaries, what actually matters is how much traffic is still running gquic, right? And I think most servers have moved over to HTTP/3?
(Disclosure: I work for Google, speaking only for myself)
Given gQUIC was never _that_ broadly deployed (mostly Google and a few CDNs, IIRC), I can't imagine it would be overly significant to disable. Last I knew there were some Google properties still using gQUIC, but that was a while ago.
But this can indeed might make a difference if you're talking vulnerabilities and support - for example, iPhone 10 is vulnerable to checkm8 while models 11 and newer aren't.
superkuh(6)
1. https://blog.torproject.org/experimental-defense-website-tra...