Also very confused at how we’re spinning HTTPS as a bad thing now? Cloudflare and Lets Encrypt did significantly more for HTTPS adoption than Google anyways... and it is a bit preposterous that it is somehow being spun as a negative. It’s about security as much as it is about privacy...
(I am a Google employee but speaking entirely in a personal capacity. Additionally, I do not work on Chrome or QUIC.)
> GET /index.html HTTP/1.1
> Host: example.com
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://example.com/index.html
On the other hand, on a typical secured WiFi connection over TCP over an Ethernet connection, like 10 times more complicated stuff is going on in protocols and the software stack. It’s not as if we went from bit banging HTTP directly down an Ethernet cable to a hopelessly complex stack of software; we just added another element of complexity at the application layer in exchange for real security and privacy benefits. Example.com doesn’t need it but it has become a best practice for good reason so it is used on most of the net even when not strictly necessary.
Enforcing HTTPS is a best practice because an absurdly overwhelming majority of user agents, like 4 or 5 nines of them, support HTTPS and the redirect ensures they use HTTPS and makes downgrade attacks a little more involved.
Over the past decade I've helped maybe 100 small businesses set up internet presence, and I promise you none of them understand https or set it up correctly at first, despite often paying for it from hosting providers like Godaddy.
This isn't the fault of the engineers behind implementing it; it was necessary of course. But if the web were a perfect authoritarian regime we could have just saved us all the headache and dropped http altogether, thus avoiding this bureaucratic protocol redirecting mess.
I would be very interested to read about why that was not done actually. (I'm sure there were reasons)
> the following second level domain names reserved which can be used as examples.
> example.com
$ telnet example.com 80
Trying 2606:2800:220:1:248:1893:25c8:1946...
Connected to example.com.
Escape character is '^]'.
GET /index.html HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
...
Content-Length: 1256
...If you’re comparing it to HTTP/1.1, the performance improvements are generally a lot better than that. The latency improvements are commonly something around that, but the total page loading performance will tend to be better because you get proper multiplexing.
But then you may say, why do we need this instead of HTTP/2, which had proper multiplexing? Well, it improves things a bit further, commonly improving throughput and latency by 1–10% if I’m recalling the right figures; but more importantly, it fixes the TCP head-of-line blocking issue that made HTTP/2 often actually perform a lot worse than HTTP/1.1 on low-quality connections.
I know of sites that have held off on HTTP/2 or rolled it back because it made things measurably worse for some users, and of sites that split things across domains with some HTTP/1.1 and some HTTP/2, deliberately, purely because of the TCP HOLB issue. HTTP/3 fixes that, so that it should no longer be a question of whether you make things faster for some users at the cost of others—you can instead make it faster for everyone.
I'm curious with the multiplexing improvements if we'll see greater performance gains in the long-term as we changed how we package and bundle JS.
I've seen a significant improvement in general page performance using Webpack's chunking, where it automatically breaks up each of your components into smaller .js file and only loads them if the page uses them (basically on-demand async importing of JS files that were preprocessed with webpack).
It went from loading one giant blob of JS on every page into one primary JS file (about 25% smaller) + a bunch of tiny 1-10kb .js files that load async. A typical heavily interactive page would load 5-10 of these async files.
There's probably opportunities to go even further in breaking up the primary file (which handles the logic of which JS components to load + includes the Vue/whatever framework and other JS dependencies).
I understand the utility of "loading once and caching" stuff but for serious JS-heavy frontends the bundled JS files becoming extremely bulky (sometimes in multiple megabytes due to legacy dependencies) and ideally you'd minimize that always-cached part as much as possible.
Existing protocols like TCP and TLS are not really simpler than QUIC, you just don't think about them because we have implementations of them already. However, _changing_ TCP and TLS is extremely difficult to impossible because middleboxes snoop on traffic and mess it up in various ways. As an example, multipath TCP has been engineered to look like regular TCP and automatically downgrade to regular TCP if middleboxes can't handle it. Making this work is hard and 100% a waste of time just to work around the fact that people deploy these boxes. I believe TLS 1.3 also had deployment challenges due to middleboxes.
QUIC encrypts ~everything so that middleboxes can't make broken assumptions and manipulate traffic. Adopting it is a one time pain that enable later improvements to be possible.
There was about one year delay between the point where the protocol was initially "done" and experiments showed it could not be deployed partly because of middleboxes although also due to server intolerance (web servers that go "What? TLS 1.3? No, rather than negotiating TLS 1.2 I'll just ignore you and hope you go away you weirdo") - until the point where the revised TLS 1.3 wire spelling was finished and tested (about six months before it was published as RFC 8446)
The core idea in TLS 1.3 as shipped is that the initial setup phase looks outwardly very much like TLS 1.2 resumption. Interpreted as if it was TLS 1.2 the TLS 1.3 client claims to be trying to resume a previous connection, a TLS 1.3 server claims to accept that resumption, but really they actually just agreed a brand new connection. A TLS 1.2 server would see the resumption attempt, but it has no memory of any such prior connection (there wasn't one, the "connection ID" is just random bytes) so it offers a new one using TLS 1.2 and everything goes swimmingly.
This way of doing things allows TLS 1.3 to be as fast on first connection as TLS 1.2 was on resumption without causing problems with incompatible middleboxes or servers. It does make the "spelling" on the wire pretty weird looking though if you are used to looking at TLS 1.2.
The other essential goal was to never back off. A TLS 1.3 client will never go "Huh, TLS 1.3 didn't work, let's try again with TLS 1.2 instead". The design means if the remote server can speak TLS 1.2 (or 1.0 or 1.1) it will respond as such to your TLS 1.3 connection. This means adversaries can't try to "downgrade" you to a bad older version.
It is possible to use HTTP/2 without HTTPS, but the problem is that there were a lot of systems that modified unencrypted HTTP traffic and got confused by HTTP/2 protocol - it looked nothing like HTTP/1. The easiest workaround for this issue was to require HTTPS, so that's what was done.
Also when HTTPS is being used the server can say during TLS handshake that it supports HTTP/2 avoiding the cost in having to figure out whether the server supports HTTP/2 - this cannot be done with HTTP as there is no handshake. If a web browser were to assume the server supports HTTP/2 it would make initial HTTP/1 requests slower as it would have to try HTTP/2 first (and then you would have people complaining about Google making HTTP/1 slower to make HTTP/2 look more attractive). If a web browser would say that it supports HTTP/2 it would make HTTP/2 requests slower as it would have to try HTTP/1 first (which would slow down HTTP/2 when it was supposed to be fast).
how does this increase their control?
I guess both can be true.
Right now it's possible to selectively block client activity on your network (your smart TV snooping or showing ads) but that's going to get much harder in the future. You'll have to chose all or none when it comes to clients.
And it's all done under the guise and blessing of "privacy". It's really a bleak future for the web.
Sorry, I went on a bit of tangent. But to answer your question: HTTPS makes it incredibly difficult to introspect and alter content that is flowing through the web and your browser. Allowing a user (and his ISP if done correctly) to easily at the network level alter the content, one can do all sorts of magic that we haven't even begun to explore because it's effectively impossible.
The big usage of this would be ad-blocking and removal. At this point the two biggest ad-blocking mechanisms we easily have available are: DNS-blocking of ad servers, and add-ons/plugins that are allowing introspection of the data on the web pages visited. Both of those avenues are being attacked. Add-on APIs and capabilities are being neutered in little bits and pieces both on Firefox + Chrome. And DNS is being attacked with things such as DNS over HTTPS (again under the guise of privacy).
Not to mention that even SSL certificates that allow MITM for the user are being attacked by initiatives such as embedding SSL certificates into binaries, and certificate pinning (which luckily seems to have been abandoned).
We need FOSS/Stallman-level activism and wars against this stuff that is eating away at the rights we have over our own hardware. Whatever you call this issue, it should be right up there with "right to repair", "own our own data", "right to be forgotten", etc.
Edit, wrong acronym.
I have a MITM proxy on my network that strips ads, rewrites pages with custom stylesheets, and all that across every single device connected to it, and it's hard but not impossible to set everything up, and they are only trying to make that harder.
I agree with you completely, except for "right to be forgotten" --- which tends to become interpreted more as a "right to rewrite history".
"Those who give up freedom for security deserve neither."
I'm using firefox
You control your computer - and want to mess with network traffic, make your own CA. Its not that hard.
"U.S. House's antitrust report hints at break-up of big tech firms: lawmaker (reuters.com)"
They could have shut off a large portion of IIS traffic to those that weren't running Internet Explorer.
I guess they failed because they were too late to the web - Netscape ate their breakfast.
https://www.metzdowd.com/pipermail/cryptography/2002-June/00...
The crown went from NCSA to Apache and then only recently to Nginx.
But more generally companies have written up IETF paperwork for other protocols. Lots of Microsoft protocols have RFCs for example. But one thing that's less common is actually engaging with full-blown IETF working group standards development like Google did here, as opposed to just saying "Look here's the protocol we built, you can use that, or not". The IETF is totally happy to accept what I guess you could call a "donation" of that sort, and it's much less effort. Maybe you take some internal documents, you reassemble them into the rough shape of an RFC, you publish that draft, you get a bunch of feedback about that document, focused on clarifying the explanation, making sure you cover everything required, and so on rather than altering the protocol (which you've maybe already actually shipped in a product) and after maybe 6-12 months you've got a polished RFC ready to publish.
If you use a work VPN for example, or a corporate WiFi network that's not just a few home WiFi routers with a more professional SSID and password, you probably end up using protocols Microsoft "donated" in this way, like PEAPv0/EAP-MSCHAPv2 - these protocols are awful but there was no multi-step process where other vendors improve on it and then they eventually reach consensus and publish. Microsoft shipped products that do MSCHAPv1, then wrote it up so that other products could interoperate with Windows, and when they made MSCHAPv2 they followed the same path.
Look at LetsEncrypt: A Google initiative. Yet 25% of the world’s websites use it.
No. Let's Encrypt is a service of the Internet Security Research Group, a California Public Benefit Corporation, it isn't an "initiative" of Google except in the same sense that the Red Cross is an initiative of Google, or Sweden is a US state, to make it seem "true" you need to squint so hard you can't see anything properly at all.