I'm really happy to see QUIC pushed, not because I personally have a use for it but because it's a battering ram against network non-neutrality and what I've come to call "network nerfing."
Now all those ISPs, IT departments, and cloud providers that de-prioritize or outright block UDP will get "bug reports" about things being "slow" or not working.
Now all those traffic shaping middle-boxes are worthless, and your ISP can no longer spy on your requests to gather marketing data about you.
The Internet is an IP network, not a TCP/80 and TCP/443 network.
I believe they'll still be able to do those things, though. It's just a matter of time. The slowing and spying that is. It won't be as easy, but I believe it'll be feasible. It's the typical arms race.
Or as last resort they'll legislate either to end or weaken it.
That's a laugh. Are you seriously implying people who benefit freely* from Cloudflare's state of the art network firewalls and anti-ddos shields are somehow more at risk than others because they contracted with a particular security provider instead of rolling their own security?
That assertion will require lots of hard evidence because the vast majority of indicators indicate otherwise.
This read more like an advert than a comment, and that is certainly the most loaded question I've ever seen in written English.
Giant centralized troves of personal data are a huge risk to everyone. Civilization pivots and mutates rapidly, and it's clear to nobody at any particular time which way it may lean next, or whether it will lean toward them or on top of them. If anyone had told you there'd be global mass beheadings of century-old statues 3 weeks ago, I suppose you'd have been laughing then too.
Are you aware "PRISM-like programs" apply to every single US based webserving entity? Why are you calling Cloudflare out when there's thousands of companies who are subject to the very same risk? Is it possible that PRISM programs bear no relevance at all to this conversation?
I see a chicken egg problem: Why would developers/companies abandon non-QUIC versions of their software if there is a significant chance users can't use it?
(If they even implement it under those conditions at all.)
You don't, you run them in parallel to HTTP/3 and it shouldn't add any cost for you. The work is done in the browser (or any client) to fallback to whatever works.
Then, in a few years, when you notice that most of the traffic is done over QUIC, you still won't do anything as it has no significant cost anyway and helps the few % of people who haven't upgraded their network. And customers who can use it won't notice much as your website still works anyway, but your latency metrics should be better for those users.
> Now all those traffic shaping middle-boxes are worthless
No reasonable implementation of encrypted SNI has been proposed or standardized. Those middleboxes are still more than useful
AFAIK in QUIC there is some light obfuscation of the ClientHello, but it is not intended to be an anti-filtering measure, middleboxes can still fish out any presented name with a little bit of new code
Unsurprisingly for a spec from Fastly & CloudFlare, the privacy offered is predicated on the existence of large centralized providers that due to their size cannot be blocked. One outcome of this design is that if you want to offer truly private service to an end user, you must have a relationship with one of these providers, otherwise your traffic, even if it implements the spec, becomes easily identifiable as its EKR config was served by some unique non-shared infrastructure.
In practical terms I guess it is reasonable, but viewed from the angle of how the Internet was originally intended to work, it is obviously abhorrent and self-serving.
eSNI can only effectively prevent people from distinguishing things which aren't otherwise distinguishable anyway. This is not a forgetfulness potion, if you already know by some other means where I'm going then eSNI doesn't fix that.
If cat-videos.example and elect-bob.example are just names for the same IP 10.20.30.40 then we can use eSNI to prevent eavesdroppers discovering which you visited and that's all.
But if you've got 10.20.30.40 assigned by your ISP for your personal web server then eSNI can't hide that, you can use eSNI to prevent eavesdroppers learning whether visitors were looking at snakes-control-nasa.example or soup-does-not-exist.example but if all you host are crazy conspiracy theory sites then they don't need to know which one is which to block all of them, that's just how IP works.
The configuration for eSNI is delivered over DNS, so it's up to you to choose how you want get secure DNS.
My main issue with it is exactly your preference: It is built primarily for the purpose of circumventing networking standards and norms, mostly for the benefit of big tech companies and the detriment of everyone else. QUIC is a political measure, not a standards improvement.
QUIC hides flow control parameters from the network and takes control away from the operating system, vesting more control in the application. It is the perfection of the end-to-end argument. There's nothing political about it.
It's not abundantly clear that there can be a performance benefit from moving QUIC into the kernel. Indeed, there is no performance benefit from having TCP in the kernel. That's why one of the most common tactics in high-performance networking is to move the TCP stack into userspace.
The end-to-end argument in IP networking evolved in a time (the 1970s and 1980s) when a host could reasonably be considered the endpoint. Now hosts are so big and powerful that it's no longer reasonable to draw the boundary around them. The individual process running on the host is the true endpoint, and having the application in charge of its own network flow control is the natural evolution of things.
> Indeed, there is no performance benefit from having TCP in the kernel. That's why one of the most common tactics in high-performance networking is to move the TCP stack into userspace.
But a userspace network stack only make sense in single purpose devices/servers, because they have to take over the hardware, right?
On a consumer device many applications can use the network concurrently.
QUIC runs on top of UDP anyway, so userspace libraries use OS UDP facilities, but lose the ability to do better cross-application balancing. Hardware TCP offloading also plays a role of course.
You don't have to take over the hardware to do userspace TCP. You only need the ability to put raw datagrams on the wire (Linux RAW socket, for example). You _can_ take over the device with something like DPDK but that's not necessary. As you correctly say, QUIC uses existing OS-level facilities to communicate over UDP, so there is no reason that several processes on a single host cannot use application-level QUIC stacks concurrently.
It's possible to use kernel facilities to route flows to the right application or stack, and then use that stack to process individual connections.
For example, many network cards support creating multiple virtual network devices, and you could hand a whole such device to a userspace process, but only let it see traffic intended for that device.
Or, finer-grained, you could use a filter to steer certain packet flows to a process, while handling others in the kernel.
I do absolutely think there's value in having native QUIC in the kernel, but then, I also think there's value in having native TLS in the kernel; doesn't mean you always want to use it.
> QUIC hides flow control parameters from the network
It's not clear that this is a good thing. You generally want things like network-provided congestion notification+control, and plain vanilla UDP won't be enough for this.
Well, the end-to-end argument is that you are wrong. You never want the network to do anything smart. ECN is fine, and does not require the network to have visibility into flow control parameters.
And the problem here is that I trust my network and I trust my operating system both significantly more than I trust my applications, especially as browsers have transitioned largely to being user-hostile by design.
The primary benefactor of your end-to-end argument is ad networks that also own web browsers.
Hence why this is political, it's about shifting network traffic outside of places users have control.
>Now all those ISPs, IT departments, and cloud providers that de-prioritize or outright block UDP will get "bug reports" about things being "slow" or not working.
Doubt it. I suspect that browsers have some sort of happy eyeballs algorithm for determining whether to use http/3 specifically because some networks don't handle it well. In those cases it'll fall back to http 1.1.
>Now all those traffic shaping middle-boxes are worthless
How so? how is TCP 80/443 and UDP 80/443 harder to traffic shape than TCP 80/443 alone?
> and your ISP can no longer spy on your requests to gather marketing data about you.
That's more encryption (ie. https) than switching to http/3. Also, encryption is already mandatory for http/2 (for most browsers).
So far as I can see they won't. Because QUIC (and thus HTTP/3) is always encrypted your fallback is always a TLS connection.
Modern TLS agrees the sub-protocol to use (in this case h2 = HTTP/2) early with ALPN. If that ALPN sub-protocol isn't available that same connection just becomes HTTP/1.1 (over TLS) instead.
So there's no reason to fall all the way to HTTP/1.1 without asking if HTTP/2 is available.
> Doubt it. I suspect that browsers have some sort of happy eyeballs algorithm for determining whether to use http/3 specifically because some networks don't handle it well.
On day zero? Sure. But then good networks will slowly enable UDP/443 anyway, and have good cover because it's The Web, and eventually it'll be enabled on more than 90% of networks.
Then a few non-browser applications that use QUIC/HTTPS will decide that 90% is good enough and start to not support TCP anymore, causing trouble for the holdouts and getting it enabled on 95% of networks. Then even more applications will do that.
At some point the browsers can put up a warning when fallback happens, telling the user that their network is degrading performance.
Eventually the number of networks that don't support it is small enough that nobody supports fallback anymore.
> How so? how is TCP 80/443 and UDP 80/443 harder to traffic shape than TCP 80/443 alone?
They can't mess with window sizes and such because they're inside the encrypted payload.
It would have been great if they would have used the opportunity to leverage SCTP instead of building it into QUIC. They could have defaulted to plain jane SCTP on IPv6 and tunnel it in UDP for IPv4. That would have been the perfect opportunity to drive adoption of SCTP while implementations of all sorts of middleboxes are still young enough to be swayed into supporting it. We could have all of the benefits of QUIC but with proper layer separation and multi-homing, and the ability to build future applications on it.
You can't "drive adoption" of anything new in the basic IP protocol space. You're kicking a dead mule. ISPs and IT departments don't care and have little reason to say anything but "no" or "its on the road map" (forever). The present IP stack is fixed in amber, and we'll be lucky to see IPv6 complete adoption. At this point I'd give IPv6 a 50/50 chance of failure.
Reasons for this:
* No upstream incentive due to little or no competition and not enough "killer apps."
* Security FUD: if it's new then it might allow something currently not understood.
* ISP desire to control traffic and prohibit anything new.
* First thing IT will do if there's a problem is "turn the new thing off." (This happens a lot with IPv6 even if IPv6 is not a cause.)
* Vendors with a vested interest in treating the disease (supporting technical debt) rather than curing the patient (actually fixing the problem, reducing the need for complex solutions).
My point in the original comment was that QUIC might help stop further ossification by making UDP actually necessary. Otherwise we face the potential for removal of UDP and even removal of non-standard TCP ports, eventually leading to "http only" networks. ISPs and IT departments would like that since less capability equals less support queries and less to monitor.
If IP were re-designed today I would suggest at least non-cryptographic but difficult to efficiently modify authentication of all fields (e.g. keyed or nonced checksums), and obfuscation (fast minimal encryption?) of everything under the IP header. No NAT, and nothing useful to filter on. If it's visible and mutable it will become ossified since people will MITM it.
That way there would be no choice but to fix endpoint security instead of deploying firewalls and no choice but to adopt IPv6 instead of NAT. You couldn't temporarily work around fundamental problems by nerfing the net.
I think there's a general principle here. If easy short term fixes that incur long term technical debt are allowed, they will be deployed. If such a hack is deployed in a federated or decentralized system, it becomes permanent unless extra-systemic means (e.g. legislation or financial incentives) are used to force it to be removed. Therefore federated and decentralized systems should not permit such hacks. Front load the pain by forcing the problem to actually be fixed.
This is one thing block chains kind of get right. Everything is cryptographically hashed and authenticated. You can't modify state unilaterally. You either have a compliant node or you don't, and changes must be adopted globally either as soft or hard forks.
At $work, udp/443 is blocked to the internet specifically because our corporate proxy can't deal with QUIC and Chrome tries using it a lot.
Companies have a legal and moral imperative to see what content is leaving their network, and until some combination of host/network governance is developed to only allow pre-authorized traffic to egress, MITM boxes will need to be supported.
> Companies have a legal and moral imperative to see what content is leaving their network, and until some combination of host/network governance is developed to only allow pre-authorized traffic to egress, MITM boxes will need to be supported.
"a legal and moral imperative"? No. Such networks are security threats and should be repeatedly broken until they give up. It will become increasingly expensive to even try. And an increasing number of security researchers will find ways to make maintaining MITM technologies more difficult and less transparent.
You can block spam and outbound attacks without MITMing traffic. MITMing traffic is not about protecting the outside world in any way. It's technology sold to companies out of fear (or misguided regulatory requirements). One day it will go the way of the virus scanner: dead, worse than useless, and only existing to satisfy a decreasing number of corporate checkboxes.
You completely ignore the concept of data breaches and preventing them. You complain about the alleged problem, "man in the middle" technologies, without any proposed solution.
Let me be clear: If you do not think private companies and businesses have a right, and sometimes an obligation, to secure and monitor the traffic on their networks, then you are flat out incorrect, and this conversation can end.
If you agree they need to monitor data, but that MITM technologies are a societal risk more than a benefit, I am all ears. Host-based data scanning at an OS level; signed traffic that the network can trust has been scanned by authorized hosts (so rogue hosts don't send traffic out); and so on.
edit: I don't think your message is consistent, but I think that is not a sign of malice. You say "Companies have no legal or moral need to see what content is leaving their network" then say "You can block spam and outbound attacks without MITMing traffic."
You seem to be equating "See the content leaving their network" with "MITM", but then say later that companies can "prevent outbound attacks" without MITM. The #1 threat for many companies is data loss. How do you propose DLP gets accomplished with zero access to the network?
Your employer provides you with a medical insurance plan. On your break at work, you use your company laptop to access the insurer's website and use their find-a-doctor tool to search for a cancer doctor. This is a legitimate use of your work computer, after all.
Does your employer have a right and obligation to see that you're searching for a cancer doctor?
Go to a large company's IT department and find the person there you dislike the most. Do you want that person monitoring the traffic and seeing that you searched for a cancer doctor?
Now you know why so very many of us believe you are completely wrong about this.
Do you want your bank to be hacked and have a 50GB database backup with all your accounts and transaction history slow-leaked out via DNS queries?
Now you see why so many of us believe you are completely wrong about this.
To your point:
If it is their network, it's their network and their computer. Access the website from home, or from your phone, which isn't MITM'ed on the corporate network.
If it is a resource only available on the corporate network, but it is not a "company resource" such as find-a-doctor, then you can (a) accept that the company may see it, (b) contact information security and ask if they can, or (c) find another way to get the information/complain to HR/ombudsman/whatever.
It is up to the company to do the right thing when possible, which means (in our case) we don't intercept websites categorized banking, health, and a handful of others.
Information security obfuscates/blocks the showing of personally identifiable logs to the rest of IT, as well.
Again, banks (in my example) have an obligation to their millions of customers to protect their data, more than you have a right to browse a doctor tool or upload sensitive spreadsheets to your personal Google Drive to work on over the weekend.
> Do you have the right to prioritize your personal activities over your employers protection of its' data?
It is absolutely fine in many countries to use a work computer for light and occasional personal use or on breaks. And no, employers don't always have the right to monitor all traffic that isn't relevant to the business, or even files on your machine marked as personal. Really depends on the local laws though.
> You complain about the alleged problem, "man in the middle" technologies, without any proposed solution.
I don't have to provide a "proposed solution" to MITM; the proposed solution is "stop that". To the extent MITM is getting harder, that means network protocols and software is getting better.
This is like asking the makers of adblockers what their "proposed solution" is for ads, or asking the makers of spam filters what their "proposed solution" is for sending spam.
Most critically, in a standards body, the right answer to people trying to MITM is a polite and diplomatic version of "go away, your use case is invalid".
> If you do not think private companies and businesses have a right, and sometimes an obligation, to secure and monitor the traffic on their networks
They can certainly try (currently), and one of the jobs of security researchers is to ensure they fail enough that they stop trying. I also hope one day that there's enough collective bargaining power among engineers that such companies cannot successfully hire people, and that nobody ever has to be desperate enough to accept such a draconian network. I'm glad I'm in a position to be able to say I'll never work for a company that requires MITM; everyone should be able to avoid that. And the only time I'm aware of a company having an obligation is due to misguided regulations on certain narrow classes of businesses.
> MITM technologies are a societal risk more than a benefit
The company is the only one who could possibly benefit, and that's leaving aside the likely possibility of doing more harm than good; security measures work better when your users want to help you rather than thwart you. Meanwhile, the societal harm of ever allowing MITM is massive.
Right now, the biggest step I'd love to see happen is browsers (in concert) having a persistent banner for "your traffic is being MITMed" any time they're getting the wrong certificate for sites, and browsers making that impossible to remove without rebuilding the browser from source (which is a substantial barrier). Next, we can make it easy for sites to detect access from MITMed networks, and make policy decisions on that basis. Then, coalitions of sites can collectively make it expensive to MITM.
Put that together with new protocols that are increasingly desirable, and increasingly unavoidable, and which users will want, and you have a recipe for substantially reducing the number of companies willing to even try to MITM.
> then say "You can block spam and outbound attacks without MITMing traffic."
"We block outbound email ports" is not an unreasonable policy, as an example. And if someone tunnels around that, now they're spamming from their network, not yours, so it's not your fault.
> How do you propose DLP gets accomplished with zero access to the network?
"DLP" has become equated with "MITM". But you could, instead, focus on access to the data rather than interception of exfiltration. If people are trying to exfiltrate your data, they will find a way, very very easily. And there are much better ways to catch accidents. Also, most companies are still at the level of avoiding headlines like "laptop stolen with our whole database on it", which has nothing to do with MITM.
I believe you continue to ignore the obligation of businesses to protect data.
Yes, access to sensitive data is one layer of defense in depth for data exfil - absolutely on point there. But then you throw up your hands and say "oh well" if they do get data, or if they have legitimate need to see it, and try to get it out. I don't buy that.
I agree with some of your thoughts in principle: Just like I don't agree with backdoors in crypto, I applaud TLS getting stronger toward PFS and eliminating MITM. But you're naive if you think companies don't have a right or desire to monitor the systems that hold their intellectual property, and their customers' personal data.
Your bio says you work at Intel. I'd bet a month's rent that there is a MITM proxy on your corporate network.
> I believe you continue to ignore the obligation of businesses to protect data.
On the contrary. I think it's critical for businesses to protect customer data. Many customer data breaches are "someone left the S3 bucket open" or "someone had the database on an unencrypted laptop in their car" or "someone broke into the production database using a security hole we failed to patch". How many customer data breaches are "one of our employees intentionally leaked the customer database"?
The sign of a good security policy is that your employees are actively trying to help you. The sign of a bad "security" policy is pervasive word-of-mouth knowledge on how to bypass that "security" policy to get work done. Which network is more likely to experience a breach?
(I should also clarify that there's a difference between "policies for the corporate network" and "policies for direct access to the production datacenter network", as one of many examples. Lock that down to the point that you can't easily access it, and nobody can do so without oversight.)
> if you think companies don't have a right or desire to monitor the systems
Companies have a right and a desire to run ads, and yet adblockers exist, and generally speaking the adblockers win for anyone who installs one.
>Companies have a right and a desire to run ads, and yet adblockers exist, and generally speaking the adblockers win for anyone who installs one.
I see this isn't going anywhere - you didn't acknowledge that if you work at Intel, you 100% have a web proxy on your campus despite saying otherwise, and now you're comparing adblocking by a private user on their computer on their time, and someone accessing the internet from their company's network on their company's time when and uploading arbitrary data across the Internet.
Again, you make some good points interlaced with bad ones: Yes, limit desktop access to corporate servers. Have strong IAM and auditing. But you think there is some right to have all the privacy in the world on their machine on their time. I fundamentally disagree.
And would you, or whoever is doing it, stop downvoting me? Despite our disagreements, this has been a substantive argument.
I don't generally comment on my employer, and I especially don't post about their internal policies. But I think it's reasonable to post this much, insofar as it's also a question I'd also answer for anyone thinking of interviewing: no, there's no MITM proxy. (There is a proxy; it does not MITM.)
> And would you, or whoever is doing it, stop downvoting me?
1) You can't downvote people who reply to you.
2) Discussions about downvotes are off-topic.
3) Downvoting to express disagreement is explicitly allowed.
> I don't have to provide a "proposed solution" to MITM
No, my experience says you do.
The enterprise needs to prevent data breaches and data exfiltration. If you want them to move away from MITMing, then I believe you would fare better if you provided an alternative solution.
Further, unless you have some voodoo magic, preventing breaches and exfil, would still require inspecting something - whether it's at the OS, client, or data level. IOW: you are simply moving the inspection around from network to somewhere else - but it's still inspection - and invasion of the employee activities.
You don't have a right to know what network traffic is leaving your network from machines you own? Such an odd stance from a techie since this also applies to your Chromecast, Roku, Alexa, Laptop, Phone.
Exactly zero companies care about "protecting the outside world", MITM Boxes are required to have a record and scan all traffic going through your network. If PHI is exfiltrated we can't just tell the auditor "sorry ma'am we have no visibility into our network by design. Could have been from anywhere. shrug"
I'm sure there are auditors who would sign off on it, but you can't really claim that shitboxes prevent PHI exfil. This is like putting up a ten-foot-long fence a mile from the barn with the open door. You lost the battle the moment that data was viewed on any device that wasn't currently operated by a health professional with a reason to see it.
> Such networks are security threats and should be repeatedly broken until they give up.
Why the hostility towards entities that have determined their best course of action to protect THEIR networks is by focusing on the network egress pipe? Simple and efficient to focus on one chokepoint vs patching a myriad of devices + client software + client versions + OS versions + future versions etc.
> It will become increasingly expensive to even try.
Go ahead, but you're increasingly unlikely to win that battle. There's bound to be some software or version that the enterprise cannot control (e.g. prevent data exfiltration) at which point, enterprises will have no solution but turn to SSL MITM again.
Remember, it's the enterprises' network and data - not yours.
Among many other reasons, because such entities repeatedly try to weaken Internet security standards and software to accommodate their expectations. That's an attack, and deserves an appropriate response.
Also, because today, everyone doesn't always have enough choices of potential employers that they can avoid such policies.
Also, because nobody should ever get used to the idea that their network is MITMing their traffic, not least of which because that normalizes such technologies on other networks and in other contexts.
Also, surveillance technologies like this will be abused by people with power over others; there's a long history of such abuse.
And those are just the reasons off the top of my head.
> Go ahead, you're increasingly unlikely to win that battle.
What happens when libraries and software starts dropping support for old, insecure protocols, and the new protocols are designed to treat MITM as an attack? What happens when, even before that, companies that MITM have to replace cheap MITM infrastructure with incredibly expensive MITM infrastructure? What happens when software and services start treating the resulting decreasing percentage of companies that try to MITM the way they treat companies still running IE6, and tell them "you'll have to upgrade your network"? What happens when people trying to MITM find they can't run modern software stacks, and their auditors complain that they're not upgrading? What happens when they're spending huge amounts of money maintaining forks and patches? What happens when the engineers who would have to maintain those patches don't want to work on a hostile network, and the ones that remain are more expensive? There are many things people can do to make life difficult for anyone trying to MITM.
You seem to be conflating enterprise and home/personal networks. They are not the same.
> nobody should ever get used to the idea that their network is MITMing their traffic
and:
> surveillance technologies like this will be abused by people with power over others
Then simply do not add a CA or self-signed cert to your cert store. IOW: the default is secure against SSL MITM. Nothing to "get used to" or "abused".
> What happens when libraries and software starts dropping support for old, insecure protocols, and the new protocols are designed to treat MITM as an attack?
Much simpler than you think. In an Enterprise, they block what they cannot inspect. Clients do not own+run the networks, the enterprise does.
> What happens when they're spending huge amounts of money maintaining forks and patches?
This runs counter to your earlier argument: "You can block spam and outbound attacks without MITMing traffic."
How do you control a myriad of versions of client software on a myriad of versions of devices across a myriad number of applications? There are bound to be some software the Enterprise cannot control (e.g. proprietary, or simply does not have the resources to fix+recompile).
> Then simply do not add a CA or self-signed cert to your cert store. IOW: the default is secure against SSL MITM. Nothing to "get used to" or "abused".
Once upon a time, there were public CAs who would sell you a sub-CA certificate for use on a hardware MITM box, so that you could "transparently" MITM systems on a network without adding a CA. That is now considered unacceptable, and grounds for terminating a CA. What "security" practices in use today will we be saying "once upon a time" about years from now?
> What "security" practices in use today will we be saying "once upon a time" about years from now?
Can an industry not mature?
Previous behavior is not an indicator of the future - and anyone worried about it can contribute to scrutinizing CA's and their guidelines today.
Not sure pre-judging current actors based on past actions during a relative nascent industry gets us anywhere - especially since you still haven't provided an alternative solution for enterprises to prevent data breaches or data exfiltration WITHOUT inspection happening somewhere else other than the egress chokepoint.
Controlling exfiltration by blocking ports. That's cute.
There are SO many ways to exfiltrate data. The only way to control exfiltration with a chance of success greater than zero is to lock down all work devices (at the OS level, centrally managed) and prohibit outside devices including USB keys. Anything less is a joke.
The majority of shaping/policing happens on layers below layer 7 - most of the shapers will be working as before. Also since most of the modern web traffic is TLS encrypted, your ISP already can’t spy on you - unless they are doing some kind of a TLS proxy, which is trivial to notice.
Far from it. It's quite likely going to be over 5 years if not a decade before it would be possible to run a pure-HTTP3 service without risking connectivity problems
The problem is similar to the IPv6 transition, except thanks to the browser monopolies, it's possible at least for network providers to quickly feel significant pressure to fix their networks. But there will always be some networks that will never be fixed
edit: for those inexplicably downvoting this, please pay attention to the parent comment's question, and the Internet's long chequered history of adopting new protocols in any setting. TCP port 443 isn't going to magically disappear overnight, or indeed any time soon. This is evidently true because it has been true for all prior transitions. Mail still flows to many places unencrypted despite the standardization of STARTTLS 21 years ago. The long tail has only gotten much longer in those intervening 21 years.
HTTP/2 and HTTP/3 do not change the semantics of HTTP. That means you can run reverse proxies to server HTTP/1 services as /2 and/or /3 and vice-versa. As a result the transition will be a lot easier than the transition to IPv6. I expect that the transition in corporate networks will be faster -- the opposite of the IPv6 case -- because there is a lot of appeal to HTTP/3.
I thought the primary appeal of HTTP/3 is for mobile clients, and bad connections in general, because it circumvents TCP head of line blocking and connections can persist across networks.
That doesn't feel terribly relevant in corporate networks.
(not disputing that it's not comparable to the v6 transition)
His claim of corporate appeal is completely unsubstantiated and I think when he says corporate he isn't referring to enterprise.
Enterprises largely won't give two shits about HTTP/3.
Just last week I took ownership of another department's decade old app written in VB.NET WinForms. The former dev team was putting the finishing touches on the C# WebForms refactor. It's been interesting taking a step back in time to Dev practices from 2008.
It's not nil. For "connected" UDP sockets, it's smaller than TCP's, but not nil because, well, buffers. And for non-connected UDP sockets there's still buffers. The main thing is that you can have much less buffer space because you might always be willing to drop packets. Ultimately you can have much lower memory pressure from those buffers and the smaller PCBs.
Qualys' "SSL Pulse" says 47.1% of surveyed sites offered HTTP/2 and about 30% of surveyed sites offer TLS 1.3
Increasingly "corporations" out-source this problem to specialists who are only too pleased to use newer technologies with better performance and collect the same money.
Because 47% of sites run on Cloudflare or similar CDN that started enabling HTTP/2 for non-paying customers.
The application servers running the site do not accept HTTP/2 and most likely can't support it at all (we're a python shop and none of the web frameworks we use could do HTTP/2 when we looked into it).
For HTTP/2 at least, I think the main benefit in terms of performance applies to the "last hop", so you still get a more reliable experience even if the connection between the CDN/proxy and app server is http/1.1
True, through many web-sites don't have to care about the performance difference.
But for companies like CloudFlare or Googl HTTP/2 means less traffic overhead (multiplexing+header compression) and can save them a lot of bandwidth (aka. money) with that.
But exactly that's the point. It can be handled transparently in a much easier way then the Ipv6 switch. (Because IPv6 is so much more different then just IPv4 + more addresses, and worse, many people don't realize it and treat it as IPv4 with more addresses which resulted in many problems).
The transition will be faster because of that a big chunck of the internet is gatewayed through a few big players (e.g. Cloudflare, AWS, CDNs, the new wave of static deployment services like Netlify and Zeit.co, big websites like google, facebook, netflix, etc...)
This is only mostly true, they do subtly change some semantics.
As a motivational example, it is possible to encode a colon in a header name in http2 but not in http1.1, and this does not violate the RFC which only blacklists "\0\r\n".
See, that will NEVER happen. Completely impractical. SCTP has a different protocol number in the IP datagram header and many devices will either drop or malfunction when faced with protocol numbers they don't understand. UDP and TCP (protocol numbers 6 and 17) are well-supported, by practically all devices.
Aaaa, you mean the problem of -smart- stupid pipes. These do and will exist all the time and this is an opportunity for them to realise how detrimental they do is to Internet.
UDP is as clean as you can get it. It is more or less free of any overhead. And networks know UDP already. A new IP protocol is far more likely to be rejected in the network.
There are a ton of networks (think big corporate networks, schools, shared apartment wifi) that enforce too many weird port restrictions. Many of those places rarely get network or config updates. I don't think it's as bad as IPv6, but there are a lot of people for whom it isn't going to just work out of the box.
"Network providers" isn't really the issue. It's all the corporate and school networks that block UDP, or run broken spyware MITM boxes, etc. Chrome has to do a TCP vs UDP race to figure out if UDP connectivity to the internet is broken.
In some cases it is the ISPs. I'll share an example:
Some broadband ISPs struggle with the fact that their customers get compromised and join botnets. Over the last few years UDP has become the ddos attack of choice. Broadband access networks struggle with how to mitigate this. Some try to block the command and control (C2) and some try to go the customer outreach angle. For example, notifying them that they have a compromised machine or putting them in a walled garden with a website that pops up telling them they've been impacted. The problem is that outreach is costly and not super effective. So they found another option: apply throttles on UDP. A few have done this and it's led to big problems because from a user experience QUIC works enough - and then falls apart.
Some of the access providers have changed the throttles to be less aggressive while others have resorted to being aggressive on the topic ("you should have made a new protocol and consulted with us!").
Maybe similar but much smaller then IpV6 with much less problems, because most web frameworks will transparently support HTTP/1, HTTP/2 and HTTP/3 for the large majority of use-cases.
> Mail still flows to many places unencrypted
Mainly because getting a TLS certificate wasn't that easier for a lot of people in the world until recent years and the standard being written in a way which can be easily (mis-) understood as you having to have support unencrypted sending/receiving of mails. (It requires it for sending for local, i.e. implicitly by OS user account authenticated same machine mail.).
> Far from it. It's quite likely going to be over 5 years if not a decade before it would be possible to run a pure-HTTP3 service without risking connectivity problems
There won't be a pure HTTP/3 service anyway. HTTP/3 requires negotiation. It is announced from a previous HTTP/1.1 or /2 request using a "Alt-Svc" header. Typical clients will not try to connect using HTTP/3 directly
Many corporate proxies are HTTP proxies (as opposed to SOCKS) as well, which are currently by definition TCP. Not sure if an QUIC proxy would be easy to implement at all.
It should be completely transparent; unfortunately, there are way too many networks with firewalls configured to only allow known ports of known protocols, instead of following the design principle that only the end hosts should care about layers above IPv4 and IPv6. Since QUIC and HTTP/3 uses UDP instead of TCP, these firewalls will drop or reject the connection.
That is: any network that is capable of handling traditional HTTP is capable of handling HTTP/3, but many are explicitly configured to not do so.
There are a lot of broken networks. HTTP/2 and even HTTP/1.1 ran into this.
But really the idea of the protocol being transparent to the network is completely backwards in relation to the main idea of the Internet, namely the end-to-end principle, which says that the network is dumb and is not allowed to look inside the IP packets into the higher level protocols.
I see UDP as superior in general, and don't see a good reason to use SCTP at this point for any real use case.
IMO, it's a "good thing" for applications (or types of application) to have control over the Transmission Layer since the characteristics that each type of application might desire is different. Want your app to use raw UDP sockets? Easy. Want to use QUIC? Use a QUIC library. HTTP/3? Use and HTTP/3 library.
If it all used SCTP, you are locked in to its feature set and are likely to end up with new problems similar to what we see with TCP.
I could possibly UDP/QUIC taking over TCP in a long, long while, but SCTP is not likely to ever be usefully supported because there isn't a compelling reason to do it.
In a few years most of middle boxes should supports TFO.
So when HTTP3 implementations will be mature, TFO should too. The advantages of HTTP3 over it are uncertain
Its kind of an apples and oranges comparison, isn't it? If you care about failure modes and head of line blocking then HTTP/3 has features HTTP/2 does not.
eSNI isn't finished and time resolutely insists on moving in one direction, so a document which says "Use this thing that will exist in the future" isn't useful today.
there is an implementation in Firefox (although I don't know if it matches the current state of the spec draft) that unsurprisingly is gated behind an about:config flag.
isn't finished => the standard of it isn't finished so implementations might not to change quite a bit over time and might not be compatible with each other
My only problem is why force TLS when we have better protocols nowadays. We did some research on using noise (in addition to TLS) but I’m not sure anyone really pushed for this to be considered officially (cf nQUIC)
There is nothing precluding HTTP/3.1 from switching up some aspect of the protocol. TLS was probably selected here because it is mature and well supported.
The problem is in how the specs are deeply mixed with TLS. We advocated for the specs to be more flexible so that we could extend QUIC to be specified with noise as well but I don’t believe that has happened.
Also TLS was selected because of regulations. Which is damning to say the least.
The benefit of TLS is widely deployed certificate infrastructure. If you could find a way to keep the server certificate infrastructure intact while cutting out most of the ugliness of TLS, that'd probably be a workable solution.
FWIW though, TLS 1.3 (the only currently supported TLS in QUIC, AFAIK) is a lot less hairy than TLS 1.2 and earlier; and most of the primitives are the same as you would use for noise (i.e. standard AEADs like ChaCha20-Poly1305).
We have actual security proofs for TLS 1.3 (which is the only version offered in QUIC)
Of course such proofs come with caveats - in particular the proofs assume your cryptographic primitives work as intended (e.g. that AES isn't broken) and that you've implemented the specification and not something else - but our experience has been that it's valuable to get those proofs, and where proof turns out to be difficult it's a valuable pointer to weaknesses in your design.
As far as I know nobody has done such a proof for the Noise design, and so we only have our intuition that it looks safe.
AFAIK Noise has end-to-end proofs of correctness using CryptoVerif, the work having mostly been done by the Prosecco team at INRIA. You can explore Noise protocols on NoiseExplorer [0][1]
Also I may be wrong again, but it is for TLS, that even with all the simplifications and major changes on TLS 1.3, that we only have proofs of correctness for certain subsets of the spec, and specific modes of operation (theres a version of the protocol targeting IoT for which this work has been done, but I can't remember the name)
I loved the nQUIC paper. It's really sad that QUIC has not been thought of as a "meta" protocol of sorts, where you can bring your own crypto (or none at all). I find it kind of annoying that I can't use QUIC for intra-cluster communication with the crypto disabled, and leaving those preocupations for a service-mesh layer, or even just overlaying the entire cluster with a WireGuard VPN.
There are legitimate use cases for "running naked", but now we're doomed to jerry-rigging some BS ephemeral self-signed certificates in order to use any QUIC client that follows the official spec.
All I would like is an unencrypted version of QUIC for low overhead stuff where privacy/security isn't a concern such as experimental, CAN, or air-gapped networks. This has been staunchly rejected unfortunately :/
There are reasons for that beyond crypto-everywhere-goodness - in the main use case crypto helps prevent middleboxes from messing with things which is critical for its success.
Funny that - I thought the advantage of unencrypted HTTP was so that middleboxes could do things like caching (squid, etc) and outbound deep packet inspection to prevent information leaks in corporate environments.
Middleboxes can still do that, assuming they have a valid SSL certificate. But that obviously makes it a -trusted- middlebox, not say, your ISPs middlebox.
If they actually do this correctly† then sure, you get security in the sense that you decided to trust My Corp Monkey Proxy to do whatever corporate monkeying, and nobody else can meddle with that.
†The correct way to proxy HTTPS is wire a client and server with your meddling code in between, your client negotiates a TLS connection to say https://news.ycombinator.com/ and it decides exactly what is sent and can see in plaintext exactly what's received. Users make TLS connections to your server and it presents them with a certificate it made, maybe claiming to be news.ycombinator.com and signed by My Corp Monkey Proxy then passes through some requests to the client we described.
But it's much cheaper not to do this, and all of the other things you might do to achieve the same goal are insecure or break the protocol or both. So there's a big financial incentive to destroy security, while often ironically claiming to be improving security e.g. anti-phishing. For example choosing random number is hard yet at the same time essential for security - so several major vendors sold products that just didn't. When they turned A->B into A->M->B with their product as M, they'd just re-use the random numbers from the other conversation in the pair. This had been destroying security for all their customers for years, but we only found out they were doing it because it broke with TLS 1.3 final.
Specifically when a TLS 1.3 server (but not draft versions for important compatibility reasons) talks to a client that doesn't agree to TLS 1.3 it scribbles the letters "DOWNGRD" over part of the random number field. Since the client supposedly doesn't know TLS 1.3 it shouldn't care, DOWNGRD is a ludicrously unlikely "random" choice but so is "FCKTRMP" or "KICKASS" and those don't mean anything in older TLS versions either. But if the client really does speak TLS 1.3 and has somehow been tricked into negotiating an old version, this weird choice of "random" number signals it's a trick and it will disconnect.
The affected "proxies" would tell a nice shiny new Chrome or Firefox (which can speak TLS 1.3 and thus are looking out for DOWNGRD) that they only knew TLS 1.2, fair enough. And they'd tell servers, say www.google.com, the same thing. But the TLS 1.3 capable servers would scribble DOWNGRD into their random number field, and then because these "proxies" weren't actually assembled from a separate client and server but just re-used all the numbers, the DOWNGRD gets copied into data received in Chrome, and it disconnects because it has seemingly detected an active attack.
This is all great information. FWIW, managing and automating anycasted 'middleboxes' for others is part of my work. The scary part, to me, is what paying customers demand. Largely, they don't want to fix broken or legacy systems, but just want an A+ on SSL-Labs. Of course, you can imagine the security implications of downgrading, or worse, terminating the TLS connection at the proxy. The end user has no idea their data is being sent in plaintext over the open web. I won't do such things, but I'm sure plenty of other companies are willing.
I think QUIC-the-transport is potentially an interesting transport for storage, but the data there is often already encrypted, so the double encryption is a waste.
Is it possible to only encrypt the QUIC headers but leave the data unmodified? That idea just popped into my head and I'm not sure it makes any sense, but maybe that would provide the best of both worlds.
How well does QUIC perform over networks with relatively high packet loss? It seems like Aspera (https://www.ibm.com/products/aspera) is the industry standard for high performance WAN transfers, but it's a proprietary protocol. I'm wondering if QUIC performs better than HTTP1/2 in this respect?
The drafts don't seem to mention that this use case would be at the forefront or better than with HTTP/2, got any pointers?
Generally high loss is not well tolerated by internet protocols, so high loss networking technologies tend to handle forward error correction and retransmissions in protocol layers below IP.
TCP works by slowing the data rate when data loss happens. On purpose, to be fair!
I think it's not that hard to write a program/protocl that blasts out a big file over UDP and just sends all the parts as packets, then waits for the receiver to assemble a big list of missing packets, send them back and have the sender blast out everything again at a high rate.
But this would be at the expense of all the other TCP connections.
Wasn't QUIC changed to be so called "TCP friendly", that means that it has the same back off behaviour as TCP so that if you are in a crowded hot spot every tcp stream has a fair chance?
(On the other site, google and some other companies have a huge initial TCP window size and try (or tried?) to send e.g. the whole google homepage with like 8 1500 byte packets at once, also trying to get a better ux than other, again on the expense of other TCP streams)
Looks like using Aspera is unfair and only works if a few people do it.
My understanding is that the protocol underlying Aspera (FASP) uses UDP for the main data transfer and a TCP connection for coordination. By using UDP for data transfer it's not restricted to the ACK ranges imposed by TCP which can hinder throughput on networks with relatively high packet loss. Its throughput is not necessarily achieved by being a "bad citizen" but by having full control over how and when it communicates lost packets.
Since QUIC is also over UDP, perhaps we now have more flexibility on ACK windows etc.
My understanding is that window scaling and SACKs enable TCP to detect losses within large segments too. The only limitation is that most congestion controllers throttle back when detecting packet loss. Newer latency-based controllers don't suffer from that problem.
This is interesting. I haven't seen much in regard to comparing TCP+BBR to FASP other than a masters thesis which suggests FASP outperforms on transferring large files over long distances (which is exactly its intended purpose).
But, I wonder if splitting a file over multiple QUIC connections and re-assembling at the other side would come closer to the performance of FASP? Could be a fun experiment, I might try it!
An optimal CC should have high utilization with a single stream¹ and behave fairly to other connections on the network. Measuring multiple streams misses the point of the exercise.
> other than a masters thesis which suggests FASP outperforms on transferring large files over long distances
I found that one too. I would take it with a grain of salt since it uses scp for data transfer (which has its own flow control and may be the limiting factor here) and doesn't list the values of some important tcp settings, e.g. tcp_wmem, which can be essential for transoceanic connections.
¹ ignoring the case where a single CPU core can't move bytes fast enough to saturate a link.
They are probably comparing their product to classic TCP congestion controllers running on long fat pipes with high packet loss. If you swap in BBR that advantage will probably shrink or vanish.
153 comments
[ 3.5 ms ] story [ 192 ms ] threadNow all those ISPs, IT departments, and cloud providers that de-prioritize or outright block UDP will get "bug reports" about things being "slow" or not working.
Now all those traffic shaping middle-boxes are worthless, and your ISP can no longer spy on your requests to gather marketing data about you.
The Internet is an IP network, not a TCP/80 and TCP/443 network.
Or as last resort they'll legislate either to end or weaken it.
I hope I'm mistaken, though.
That assertion will require lots of hard evidence because the vast majority of indicators indicate otherwise.
* free or less than 20$/mo
Giant centralized troves of personal data are a huge risk to everyone. Civilization pivots and mutates rapidly, and it's clear to nobody at any particular time which way it may lean next, or whether it will lean toward them or on top of them. If anyone had told you there'd be global mass beheadings of century-old statues 3 weeks ago, I suppose you'd have been laughing then too.
Then, in a few years, when you notice that most of the traffic is done over QUIC, you still won't do anything as it has no significant cost anyway and helps the few % of people who haven't upgraded their network. And customers who can use it won't notice much as your website still works anyway, but your latency metrics should be better for those users.
No reasonable implementation of encrypted SNI has been proposed or standardized. Those middleboxes are still more than useful
AFAIK in QUIC there is some light obfuscation of the ClientHello, but it is not intended to be an anti-filtering measure, middleboxes can still fish out any presented name with a little bit of new code
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
... do you feel is unreasonable?
In practical terms I guess it is reasonable, but viewed from the angle of how the Internet was originally intended to work, it is obviously abhorrent and self-serving.
If cat-videos.example and elect-bob.example are just names for the same IP 10.20.30.40 then we can use eSNI to prevent eavesdroppers discovering which you visited and that's all.
But if you've got 10.20.30.40 assigned by your ISP for your personal web server then eSNI can't hide that, you can use eSNI to prevent eavesdroppers learning whether visitors were looking at snakes-control-nasa.example or soup-does-not-exist.example but if all you host are crazy conspiracy theory sites then they don't need to know which one is which to block all of them, that's just how IP works.
The configuration for eSNI is delivered over DNS, so it's up to you to choose how you want get secure DNS.
That's just because QUIC is a new, not yet specified protocol, isn't it?
Kernels will get support eventually. Microsoft is actually already shipping some code. [1]
Browsers will probably switch to OS facilities once they are mature enough and provide a performance benefit.
[1] https://www.windowslatest.com/2018/04/03/microsoft-to-add-su...
The end-to-end argument in IP networking evolved in a time (the 1970s and 1980s) when a host could reasonably be considered the endpoint. Now hosts are so big and powerful that it's no longer reasonable to draw the boundary around them. The individual process running on the host is the true endpoint, and having the application in charge of its own network flow control is the natural evolution of things.
But a userspace network stack only make sense in single purpose devices/servers, because they have to take over the hardware, right?
On a consumer device many applications can use the network concurrently.
QUIC runs on top of UDP anyway, so userspace libraries use OS UDP facilities, but lose the ability to do better cross-application balancing. Hardware TCP offloading also plays a role of course.
For example, many network cards support creating multiple virtual network devices, and you could hand a whole such device to a userspace process, but only let it see traffic intended for that device.
Or, finer-grained, you could use a filter to steer certain packet flows to a process, while handling others in the kernel.
I do absolutely think there's value in having native QUIC in the kernel, but then, I also think there's value in having native TLS in the kernel; doesn't mean you always want to use it.
It's not clear that this is a good thing. You generally want things like network-provided congestion notification+control, and plain vanilla UDP won't be enough for this.
https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...
The primary benefactor of your end-to-end argument is ad networks that also own web browsers.
Hence why this is political, it's about shifting network traffic outside of places users have control.
Doubt it. I suspect that browsers have some sort of happy eyeballs algorithm for determining whether to use http/3 specifically because some networks don't handle it well. In those cases it'll fall back to http 1.1.
>Now all those traffic shaping middle-boxes are worthless
How so? how is TCP 80/443 and UDP 80/443 harder to traffic shape than TCP 80/443 alone?
> and your ISP can no longer spy on your requests to gather marketing data about you.
That's more encryption (ie. https) than switching to http/3. Also, encryption is already mandatory for http/2 (for most browsers).
Modern TLS agrees the sub-protocol to use (in this case h2 = HTTP/2) early with ALPN. If that ALPN sub-protocol isn't available that same connection just becomes HTTP/1.1 (over TLS) instead.
So there's no reason to fall all the way to HTTP/1.1 without asking if HTTP/2 is available.
On day zero? Sure. But then good networks will slowly enable UDP/443 anyway, and have good cover because it's The Web, and eventually it'll be enabled on more than 90% of networks.
Then a few non-browser applications that use QUIC/HTTPS will decide that 90% is good enough and start to not support TCP anymore, causing trouble for the holdouts and getting it enabled on 95% of networks. Then even more applications will do that.
At some point the browsers can put up a warning when fallback happens, telling the user that their network is degrading performance.
Eventually the number of networks that don't support it is small enough that nobody supports fallback anymore.
> How so? how is TCP 80/443 and UDP 80/443 harder to traffic shape than TCP 80/443 alone?
They can't mess with window sizes and such because they're inside the encrypted payload.
Reasons for this:
* No upstream incentive due to little or no competition and not enough "killer apps."
* Security FUD: if it's new then it might allow something currently not understood.
* ISP desire to control traffic and prohibit anything new.
* First thing IT will do if there's a problem is "turn the new thing off." (This happens a lot with IPv6 even if IPv6 is not a cause.)
* Vendors with a vested interest in treating the disease (supporting technical debt) rather than curing the patient (actually fixing the problem, reducing the need for complex solutions).
My point in the original comment was that QUIC might help stop further ossification by making UDP actually necessary. Otherwise we face the potential for removal of UDP and even removal of non-standard TCP ports, eventually leading to "http only" networks. ISPs and IT departments would like that since less capability equals less support queries and less to monitor.
If IP were re-designed today I would suggest at least non-cryptographic but difficult to efficiently modify authentication of all fields (e.g. keyed or nonced checksums), and obfuscation (fast minimal encryption?) of everything under the IP header. No NAT, and nothing useful to filter on. If it's visible and mutable it will become ossified since people will MITM it.
That way there would be no choice but to fix endpoint security instead of deploying firewalls and no choice but to adopt IPv6 instead of NAT. You couldn't temporarily work around fundamental problems by nerfing the net.
I think there's a general principle here. If easy short term fixes that incur long term technical debt are allowed, they will be deployed. If such a hack is deployed in a federated or decentralized system, it becomes permanent unless extra-systemic means (e.g. legislation or financial incentives) are used to force it to be removed. Therefore federated and decentralized systems should not permit such hacks. Front load the pain by forcing the problem to actually be fixed.
This is one thing block chains kind of get right. Everything is cryptographically hashed and authenticated. You can't modify state unilaterally. You either have a compliant node or you don't, and changes must be adopted globally either as soft or hard forks.
Companies have a legal and moral imperative to see what content is leaving their network, and until some combination of host/network governance is developed to only allow pre-authorized traffic to egress, MITM boxes will need to be supported.
"a legal and moral imperative"? No. Such networks are security threats and should be repeatedly broken until they give up. It will become increasingly expensive to even try. And an increasing number of security researchers will find ways to make maintaining MITM technologies more difficult and less transparent.
You can block spam and outbound attacks without MITMing traffic. MITMing traffic is not about protecting the outside world in any way. It's technology sold to companies out of fear (or misguided regulatory requirements). One day it will go the way of the virus scanner: dead, worse than useless, and only existing to satisfy a decreasing number of corporate checkboxes.
Let me be clear: If you do not think private companies and businesses have a right, and sometimes an obligation, to secure and monitor the traffic on their networks, then you are flat out incorrect, and this conversation can end.
If you agree they need to monitor data, but that MITM technologies are a societal risk more than a benefit, I am all ears. Host-based data scanning at an OS level; signed traffic that the network can trust has been scanned by authorized hosts (so rogue hosts don't send traffic out); and so on.
edit: I don't think your message is consistent, but I think that is not a sign of malice. You say "Companies have no legal or moral need to see what content is leaving their network" then say "You can block spam and outbound attacks without MITMing traffic."
You seem to be equating "See the content leaving their network" with "MITM", but then say later that companies can "prevent outbound attacks" without MITM. The #1 threat for many companies is data loss. How do you propose DLP gets accomplished with zero access to the network?
Does your employer have a right and obligation to see that you're searching for a cancer doctor?
Go to a large company's IT department and find the person there you dislike the most. Do you want that person monitoring the traffic and seeing that you searched for a cancer doctor?
Now you know why so very many of us believe you are completely wrong about this.
Now you see why so many of us believe you are completely wrong about this.
To your point:
If it is their network, it's their network and their computer. Access the website from home, or from your phone, which isn't MITM'ed on the corporate network.
If it is a resource only available on the corporate network, but it is not a "company resource" such as find-a-doctor, then you can (a) accept that the company may see it, (b) contact information security and ask if they can, or (c) find another way to get the information/complain to HR/ombudsman/whatever.
It is up to the company to do the right thing when possible, which means (in our case) we don't intercept websites categorized banking, health, and a handful of others.
Information security obfuscates/blocks the showing of personally identifiable logs to the rest of IT, as well.
Again, banks (in my example) have an obligation to their millions of customers to protect their data, more than you have a right to browse a doctor tool or upload sensitive spreadsheets to your personal Google Drive to work on over the weekend.
Do you have the right to prioritize your personal activities over your employers protection of its' data?
Creating blindspots on enterprise networks won't get far - especially not given today's realities of breaches.
It is absolutely fine in many countries to use a work computer for light and occasional personal use or on breaks. And no, employers don't always have the right to monitor all traffic that isn't relevant to the business, or even files on your machine marked as personal. Really depends on the local laws though.
I don't have to provide a "proposed solution" to MITM; the proposed solution is "stop that". To the extent MITM is getting harder, that means network protocols and software is getting better.
This is like asking the makers of adblockers what their "proposed solution" is for ads, or asking the makers of spam filters what their "proposed solution" is for sending spam.
Most critically, in a standards body, the right answer to people trying to MITM is a polite and diplomatic version of "go away, your use case is invalid".
> If you do not think private companies and businesses have a right, and sometimes an obligation, to secure and monitor the traffic on their networks
They can certainly try (currently), and one of the jobs of security researchers is to ensure they fail enough that they stop trying. I also hope one day that there's enough collective bargaining power among engineers that such companies cannot successfully hire people, and that nobody ever has to be desperate enough to accept such a draconian network. I'm glad I'm in a position to be able to say I'll never work for a company that requires MITM; everyone should be able to avoid that. And the only time I'm aware of a company having an obligation is due to misguided regulations on certain narrow classes of businesses.
> MITM technologies are a societal risk more than a benefit
The company is the only one who could possibly benefit, and that's leaving aside the likely possibility of doing more harm than good; security measures work better when your users want to help you rather than thwart you. Meanwhile, the societal harm of ever allowing MITM is massive.
Right now, the biggest step I'd love to see happen is browsers (in concert) having a persistent banner for "your traffic is being MITMed" any time they're getting the wrong certificate for sites, and browsers making that impossible to remove without rebuilding the browser from source (which is a substantial barrier). Next, we can make it easy for sites to detect access from MITMed networks, and make policy decisions on that basis. Then, coalitions of sites can collectively make it expensive to MITM.
Put that together with new protocols that are increasingly desirable, and increasingly unavoidable, and which users will want, and you have a recipe for substantially reducing the number of companies willing to even try to MITM.
> then say "You can block spam and outbound attacks without MITMing traffic."
"We block outbound email ports" is not an unreasonable policy, as an example. And if someone tunnels around that, now they're spamming from their network, not yours, so it's not your fault.
> How do you propose DLP gets accomplished with zero access to the network?
"DLP" has become equated with "MITM". But you could, instead, focus on access to the data rather than interception of exfiltration. If people are trying to exfiltrate your data, they will find a way, very very easily. And there are much better ways to catch accidents. Also, most companies are still at the level of avoiding headlines like "laptop stolen with our whole database on it", which has nothing to do with MITM.
Yes, access to sensitive data is one layer of defense in depth for data exfil - absolutely on point there. But then you throw up your hands and say "oh well" if they do get data, or if they have legitimate need to see it, and try to get it out. I don't buy that.
I agree with some of your thoughts in principle: Just like I don't agree with backdoors in crypto, I applaud TLS getting stronger toward PFS and eliminating MITM. But you're naive if you think companies don't have a right or desire to monitor the systems that hold their intellectual property, and their customers' personal data.
Your bio says you work at Intel. I'd bet a month's rent that there is a MITM proxy on your corporate network.
On the contrary. I think it's critical for businesses to protect customer data. Many customer data breaches are "someone left the S3 bucket open" or "someone had the database on an unencrypted laptop in their car" or "someone broke into the production database using a security hole we failed to patch". How many customer data breaches are "one of our employees intentionally leaked the customer database"?
The sign of a good security policy is that your employees are actively trying to help you. The sign of a bad "security" policy is pervasive word-of-mouth knowledge on how to bypass that "security" policy to get work done. Which network is more likely to experience a breach?
(I should also clarify that there's a difference between "policies for the corporate network" and "policies for direct access to the production datacenter network", as one of many examples. Lock that down to the point that you can't easily access it, and nobody can do so without oversight.)
> if you think companies don't have a right or desire to monitor the systems
Companies have a right and a desire to run ads, and yet adblockers exist, and generally speaking the adblockers win for anyone who installs one.
I see this isn't going anywhere - you didn't acknowledge that if you work at Intel, you 100% have a web proxy on your campus despite saying otherwise, and now you're comparing adblocking by a private user on their computer on their time, and someone accessing the internet from their company's network on their company's time when and uploading arbitrary data across the Internet.
Again, you make some good points interlaced with bad ones: Yes, limit desktop access to corporate servers. Have strong IAM and auditing. But you think there is some right to have all the privacy in the world on their machine on their time. I fundamentally disagree.
And would you, or whoever is doing it, stop downvoting me? Despite our disagreements, this has been a substantive argument.
> And would you, or whoever is doing it, stop downvoting me?
1) You can't downvote people who reply to you. 2) Discussions about downvotes are off-topic. 3) Downvoting to express disagreement is explicitly allowed.
No, my experience says you do.
The enterprise needs to prevent data breaches and data exfiltration. If you want them to move away from MITMing, then I believe you would fare better if you provided an alternative solution.
Further, unless you have some voodoo magic, preventing breaches and exfil, would still require inspecting something - whether it's at the OS, client, or data level. IOW: you are simply moving the inspection around from network to somewhere else - but it's still inspection - and invasion of the employee activities.
Exactly zero companies care about "protecting the outside world", MITM Boxes are required to have a record and scan all traffic going through your network. If PHI is exfiltrated we can't just tell the auditor "sorry ma'am we have no visibility into our network by design. Could have been from anywhere. shrug"
Why the hostility towards entities that have determined their best course of action to protect THEIR networks is by focusing on the network egress pipe? Simple and efficient to focus on one chokepoint vs patching a myriad of devices + client software + client versions + OS versions + future versions etc.
> It will become increasingly expensive to even try.
Go ahead, but you're increasingly unlikely to win that battle. There's bound to be some software or version that the enterprise cannot control (e.g. prevent data exfiltration) at which point, enterprises will have no solution but turn to SSL MITM again.
Remember, it's the enterprises' network and data - not yours.
Among many other reasons, because such entities repeatedly try to weaken Internet security standards and software to accommodate their expectations. That's an attack, and deserves an appropriate response.
Also, because today, everyone doesn't always have enough choices of potential employers that they can avoid such policies.
Also, because nobody should ever get used to the idea that their network is MITMing their traffic, not least of which because that normalizes such technologies on other networks and in other contexts.
Also, surveillance technologies like this will be abused by people with power over others; there's a long history of such abuse.
And those are just the reasons off the top of my head.
> Go ahead, you're increasingly unlikely to win that battle.
What happens when libraries and software starts dropping support for old, insecure protocols, and the new protocols are designed to treat MITM as an attack? What happens when, even before that, companies that MITM have to replace cheap MITM infrastructure with incredibly expensive MITM infrastructure? What happens when software and services start treating the resulting decreasing percentage of companies that try to MITM the way they treat companies still running IE6, and tell them "you'll have to upgrade your network"? What happens when people trying to MITM find they can't run modern software stacks, and their auditors complain that they're not upgrading? What happens when they're spending huge amounts of money maintaining forks and patches? What happens when the engineers who would have to maintain those patches don't want to work on a hostile network, and the ones that remain are more expensive? There are many things people can do to make life difficult for anyone trying to MITM.
> nobody should ever get used to the idea that their network is MITMing their traffic
and:
> surveillance technologies like this will be abused by people with power over others
Then simply do not add a CA or self-signed cert to your cert store. IOW: the default is secure against SSL MITM. Nothing to "get used to" or "abused".
> What happens when libraries and software starts dropping support for old, insecure protocols, and the new protocols are designed to treat MITM as an attack?
Much simpler than you think. In an Enterprise, they block what they cannot inspect. Clients do not own+run the networks, the enterprise does.
> What happens when they're spending huge amounts of money maintaining forks and patches?
This runs counter to your earlier argument: "You can block spam and outbound attacks without MITMing traffic."
How do you control a myriad of versions of client software on a myriad of versions of devices across a myriad number of applications? There are bound to be some software the Enterprise cannot control (e.g. proprietary, or simply does not have the resources to fix+recompile).
Once upon a time, there were public CAs who would sell you a sub-CA certificate for use on a hardware MITM box, so that you could "transparently" MITM systems on a network without adding a CA. That is now considered unacceptable, and grounds for terminating a CA. What "security" practices in use today will we be saying "once upon a time" about years from now?
Can an industry not mature?
Previous behavior is not an indicator of the future - and anyone worried about it can contribute to scrutinizing CA's and their guidelines today.
Not sure pre-judging current actors based on past actions during a relative nascent industry gets us anywhere - especially since you still haven't provided an alternative solution for enterprises to prevent data breaches or data exfiltration WITHOUT inspection happening somewhere else other than the egress chokepoint.
There are SO many ways to exfiltrate data. The only way to control exfiltration with a chance of success greater than zero is to lock down all work devices (at the OS level, centrally managed) and prohibit outside devices including USB keys. Anything less is a joke.
The problem is similar to the IPv6 transition, except thanks to the browser monopolies, it's possible at least for network providers to quickly feel significant pressure to fix their networks. But there will always be some networks that will never be fixed
edit: for those inexplicably downvoting this, please pay attention to the parent comment's question, and the Internet's long chequered history of adopting new protocols in any setting. TCP port 443 isn't going to magically disappear overnight, or indeed any time soon. This is evidently true because it has been true for all prior transitions. Mail still flows to many places unencrypted despite the standardization of STARTTLS 21 years ago. The long tail has only gotten much longer in those intervening 21 years.
I thought the primary appeal of HTTP/3 is for mobile clients, and bad connections in general, because it circumvents TCP head of line blocking and connections can persist across networks.
That doesn't feel terribly relevant in corporate networks.
(not disputing that it's not comparable to the v6 transition)
Enterprises largely won't give two shits about HTTP/3.
Just last week I took ownership of another department's decade old app written in VB.NET WinForms. The former dev team was putting the finishing touches on the C# WebForms refactor. It's been interesting taking a step back in time to Dev practices from 2008.
More availability of HTTP version gateways in load balancers and other reverse proxies is all that's needed, and that's coming along.
Increasingly "corporations" out-source this problem to specialists who are only too pleased to use newer technologies with better performance and collect the same money.
The application servers running the site do not accept HTTP/2 and most likely can't support it at all (we're a python shop and none of the web frameworks we use could do HTTP/2 when we looked into it).
But for companies like CloudFlare or Googl HTTP/2 means less traffic overhead (multiplexing+header compression) and can save them a lot of bandwidth (aka. money) with that.
As a motivational example, it is possible to encode a colon in a header name in http2 but not in http1.1, and this does not violate the RFC which only blacklists "\0\r\n".
HTTP/3 and QUIC are based on UDP. This is very different to the IPv6 transition.
Some broadband ISPs struggle with the fact that their customers get compromised and join botnets. Over the last few years UDP has become the ddos attack of choice. Broadband access networks struggle with how to mitigate this. Some try to block the command and control (C2) and some try to go the customer outreach angle. For example, notifying them that they have a compromised machine or putting them in a walled garden with a website that pops up telling them they've been impacted. The problem is that outreach is costly and not super effective. So they found another option: apply throttles on UDP. A few have done this and it's led to big problems because from a user experience QUIC works enough - and then falls apart.
Some of the access providers have changed the throttles to be less aggressive while others have resorted to being aggressive on the topic ("you should have made a new protocol and consulted with us!").
Maybe similar but much smaller then IpV6 with much less problems, because most web frameworks will transparently support HTTP/1, HTTP/2 and HTTP/3 for the large majority of use-cases.
> Mail still flows to many places unencrypted
Mainly because getting a TLS certificate wasn't that easier for a lot of people in the world until recent years and the standard being written in a way which can be easily (mis-) understood as you having to have support unencrypted sending/receiving of mails. (It requires it for sending for local, i.e. implicitly by OS user account authenticated same machine mail.).
There won't be a pure HTTP/3 service anyway. HTTP/3 requires negotiation. It is announced from a previous HTTP/1.1 or /2 request using a "Alt-Svc" header. Typical clients will not try to connect using HTTP/3 directly
Iirc it introduces use of UDP and thus will be unusable on a million corporate networks where near all UDP-traffic is filtered.
That is: any network that is capable of handling traditional HTTP is capable of handling HTTP/3, but many are explicitly configured to not do so.
But really the idea of the protocol being transparent to the network is completely backwards in relation to the main idea of the Internet, namely the end-to-end principle, which says that the network is dumb and is not allowed to look inside the IP packets into the higher level protocols.
In a parallel universe: https://tools.ietf.org/html/draft-natarajan-http-over-sctp-0... It might be that http 4 experiment this
IMO, it's a "good thing" for applications (or types of application) to have control over the Transmission Layer since the characteristics that each type of application might desire is different. Want your app to use raw UDP sockets? Easy. Want to use QUIC? Use a QUIC library. HTTP/3? Use and HTTP/3 library.
If it all used SCTP, you are locked in to its feature set and are likely to end up with new problems similar to what we see with TCP.
I could possibly UDP/QUIC taking over TCP in a long, long while, but SCTP is not likely to ever be usefully supported because there isn't a compelling reason to do it.
Also TLS was selected because of regulations. Which is damning to say the least.
I would like to read more about this. Link?
FWIW though, TLS 1.3 (the only currently supported TLS in QUIC, AFAIK) is a lot less hairy than TLS 1.2 and earlier; and most of the primitives are the same as you would use for noise (i.e. standard AEADs like ChaCha20-Poly1305).
Sure support is good but so is PGP’s
Of course such proofs come with caveats - in particular the proofs assume your cryptographic primitives work as intended (e.g. that AES isn't broken) and that you've implemented the specification and not something else - but our experience has been that it's valuable to get those proofs, and where proof turns out to be difficult it's a valuable pointer to weaknesses in your design.
As far as I know nobody has done such a proof for the Noise design, and so we only have our intuition that it looks safe.
Also I may be wrong again, but it is for TLS, that even with all the simplifications and major changes on TLS 1.3, that we only have proofs of correctness for certain subsets of the spec, and specific modes of operation (theres a version of the protocol targeting IoT for which this work has been done, but I can't remember the name)
[0] https://noiseexplorer.com/
[1] https://rwc.iacr.org/2019/slides/NoiseExplorer.pdf
There are legitimate use cases for "running naked", but now we're doomed to jerry-rigging some BS ephemeral self-signed certificates in order to use any QUIC client that follows the official spec.
I'm hopeful that the hard _requirement_ to have encryption will force better management and security.
†The correct way to proxy HTTPS is wire a client and server with your meddling code in between, your client negotiates a TLS connection to say https://news.ycombinator.com/ and it decides exactly what is sent and can see in plaintext exactly what's received. Users make TLS connections to your server and it presents them with a certificate it made, maybe claiming to be news.ycombinator.com and signed by My Corp Monkey Proxy then passes through some requests to the client we described.
But it's much cheaper not to do this, and all of the other things you might do to achieve the same goal are insecure or break the protocol or both. So there's a big financial incentive to destroy security, while often ironically claiming to be improving security e.g. anti-phishing. For example choosing random number is hard yet at the same time essential for security - so several major vendors sold products that just didn't. When they turned A->B into A->M->B with their product as M, they'd just re-use the random numbers from the other conversation in the pair. This had been destroying security for all their customers for years, but we only found out they were doing it because it broke with TLS 1.3 final.
Specifically when a TLS 1.3 server (but not draft versions for important compatibility reasons) talks to a client that doesn't agree to TLS 1.3 it scribbles the letters "DOWNGRD" over part of the random number field. Since the client supposedly doesn't know TLS 1.3 it shouldn't care, DOWNGRD is a ludicrously unlikely "random" choice but so is "FCKTRMP" or "KICKASS" and those don't mean anything in older TLS versions either. But if the client really does speak TLS 1.3 and has somehow been tricked into negotiating an old version, this weird choice of "random" number signals it's a trick and it will disconnect.
The affected "proxies" would tell a nice shiny new Chrome or Firefox (which can speak TLS 1.3 and thus are looking out for DOWNGRD) that they only knew TLS 1.2, fair enough. And they'd tell servers, say www.google.com, the same thing. But the TLS 1.3 capable servers would scribble DOWNGRD into their random number field, and then because these "proxies" weren't actually assembled from a separate client and server but just re-used all the numbers, the DOWNGRD gets copied into data received in Chrome, and it disconnects because it has seemingly detected an active attack.
https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs... actually compares them!
If you don't care about initial startup time and FEC you might see zero difference.
Is it possible to only encrypt the QUIC headers but leave the data unmodified? That idea just popped into my head and I'm not sure it makes any sense, but maybe that would provide the best of both worlds.
Generally high loss is not well tolerated by internet protocols, so high loss networking technologies tend to handle forward error correction and retransmissions in protocol layers below IP.
How is it possible to be 1000x faster? Is it?
TCP works by slowing the data rate when data loss happens. On purpose, to be fair!
I think it's not that hard to write a program/protocl that blasts out a big file over UDP and just sends all the parts as packets, then waits for the receiver to assemble a big list of missing packets, send them back and have the sender blast out everything again at a high rate.
But this would be at the expense of all the other TCP connections.
Wasn't QUIC changed to be so called "TCP friendly", that means that it has the same back off behaviour as TCP so that if you are in a crowded hot spot every tcp stream has a fair chance?
(On the other site, google and some other companies have a huge initial TCP window size and try (or tried?) to send e.g. the whole google homepage with like 8 1500 byte packets at once, also trying to get a better ux than other, again on the expense of other TCP streams)
Looks like using Aspera is unfair and only works if a few people do it.
Since QUIC is also over UDP, perhaps we now have more flexibility on ACK windows etc.
Btw. there are open protocols like Tsunami UDP (https://en.wikipedia.org/wiki/Tsunami_UDP_Protocol) that try to fill the same niche
> other than a masters thesis which suggests FASP outperforms on transferring large files over long distances
I found that one too. I would take it with a grain of salt since it uses scp for data transfer (which has its own flow control and may be the limiting factor here) and doesn't list the values of some important tcp settings, e.g. tcp_wmem, which can be essential for transoceanic connections.
¹ ignoring the case where a single CPU core can't move bytes fast enough to saturate a link.