Thanks to there always being fallback to older HTTP versions, I've never encountered an issue with HTTP/3 that prevented me from accessing a site. If HTTP/3 doesn't work, then the connection will just end up using HTTP/2 or HTTP/1.1, whichever's available.
Hopefully, yes. But one can imagine a lot of weird problems with networks treating TCP and UDP differently such that HTTP/3 performance on UDP is degraded with no fallback to earlier TCP based versions happening, because your client will only fall back if there are errors.
I think this article is specifically about running web servers inside of networks with firewalls that block udp on port 443 for whatever reason. There are lots of older networks that have such firewalls and they aren't going to get upgraded overnight.
Reaching http3 servers outside those networks is indeed not a problem as the connection gets downgraded appropriately. You'd know this when Google, for example, stops working inside your network as most of their load balancers are serving http3. Users tend to complain about these things and this obviously hasn't been happening. Ergo, connections are being downgraded as you'd expect.
But putting up webservers serving http3 in a network that blocks udp3 is indeed not going to work until somebody fixes the firewall. You could still do it and test if browsers from outside the network downgrade correctly. But that seems a bit pointless.
Every time there’s a protocol shift, the stones under which decades of ugly hacks fester are abruptly lifted, exposing them to daylight. On the one hand, those hacks tell stories that are rooted in needs, that should be respected and understood before proceeding. On the other hand, we can’t just give in to “implementation detail squatting” and never evolve our standards.
I’d love to have more rigorous analysis of what tricks are pulled, and how those can be addressed from first principles. I’ve yet to see such a take, but that’s understandable, because all this institutional knowledge is spread across segmented information islands.
At Proxmox we use HTTP/2 (h2) in our backup project to asynchronously stream chunked data to the server, works great for that and wouldn't be really possible with HTTP 1.1; at least not with major headache and extra overhead.
We also plan to closer evaluate HTTP/3 (h3) soon, mainly to see how the promised improvements, like no head of line blocking, turn out in practice for our use case.
So I'd disagree that h2 or h3 is useless "unless you're a web browser"; but sure if you use HTTP only to provide a simple text (e.g., JSON) based API it might not be _that_ relevant.
But some benefits like faster TLS setup might even make a difference there, e.g., faster initial startup, fewer packets transmitted, IIRC even packet sniffing should be a bit harder to do with h3.
If those benefits are worth it on its own, depends then probably on how easy it's to integrate in your project, iow., if your framework/standard lib/ecosystem/... already supports h3 nicely.
We use the rust hyper crate for most of our HTTP* communication, and their h3 implementation is still marked as experimental; and as we're not in a rush we'll just wait until the hyper project stabilizes h3.
No it doesn't gets serialized just by using TCP, the multiplexed streams are still handled concurrently, better utilizing the waits that come from IO heavy workloads.
Doing the same on top of http 1.1 can work but it'd be just rebuilding http 2 with more overhead; or use multiple http 1.1 connections, which takes up more OS resources and still has more overhead for binary data due to being text — and encoding to base64 then gziping or using deflate to get somewhat down im size again won't make it faster or more efficient.
But yeah on package loss there's head of line blocking, which http 3 solves by using UDP and handling the reliability on the higher level.
TCP must send all data in order. To implement that, all data sent out gets written to a retransmit buffer (which may be dynamically sized, but only up to a maximum), and that data only gets removed once acked by the other end. Once the retransmit buffer is full, you are unable to write more data; your TCP implementation would then most likely suspend your process and wake it up once it can write again.
Your thread is spending its time waiting for the other end to ack before it can send more data, delaying any other kind of work your thread has to do (such as serving other clients). The rate at which it can write doesn't magically increase by attempting to write multiple streams concurrently; quite the opposite. The rate is controlled by the other end, and what you should do if you implement a high-performance TCP service (HTTP or not) is simply disconnect clients that require you to ever block.
Now you could say, "I don't care, I write the data asynchronously". Asynchronous writes are very bad and an anti-pattern, they should typically never be used because they mean you are just queueing data indefinitely until it is eventually written, wasting massive amounts of RAM (if not taking the machine down entirely). Queues in general are serious business and require a careful design to ensure the producer doesn't produce data faster than the consumer, with adequate back-pressure algorithms. It is better to keep track of when you can write and decide on how to handle not being able to write rather than block or queue like an idiot.
Multiplexing with HTTP/2 logically makes the TCP stream which is logically a spsc queue into a pseudo-mpsc queue. Those are also way more difficult to reason about to guarantee fairness and back-pressure, they're pretty much a bottleneck by design. It's just a bad idea any way you look at it.
Sorry, but did you let GPT write this response? As from the language and the amount of misinformation it contains it'd read as good fit - not meant to take as stab at you; just trying to fine tune my "detection heuristics" for such stuff.
> TCP must send all data in order. To implement that, all data sent out gets written to a retransmit buffer (which may be dynamically sized, but only up to a maximum).
To a send buffer, at least that's what most TCP implementation name it and with modern surprisingly high reliable networks it's mostly used for that. But yes, again (3rd time now), this is head-of-line blocking which HTTP/3 would solve (and which you also classified as being just useful for web browsers, whatever that even means).
More important, yes while TCP is in-order and if the network is slow and/or drops a lot of packets you will notice that, BUT it can batch multiple HTTP requests into single TCP package and that's why an async concurrent or even parallel application can benefit from using it directly.
> Your thread is spending its time waiting for the other end to ack before it can send more data, delaying any other kind of work your thread has to do (such as serving other clients).
No it doesn't, as we are fully async on all layers with rust's zero-cost async model, e.g. using the async tokio rust crate, it can just continue to handle other requests.
Also, what would change here by using HTTP/1.1? It has the same limitations as it also uses TCP, but additionally can't batch multiple requests into single TCP packets is text based (bad for binary data) and has additional down sites - e.g., slow on start up.
> Now you could say, "I don't care, I write the data asynchronously". Asynchronous writes are very bad and an anti-pattern, they should typically never be used because they mean you are just queueing data indefinitely until it is eventually written, wasting massive amounts of RAM (if not taking the machine down entirely).
Note that 1) we're talking mostly about reads here, and 2) async writes where never that bad and especially nowadays we're not in the spinning-rust-HDDs-only era anymore, so I'd recommend getting that rather dated and never quite right view updated.
How would async writes even take down a machine? The kernel just uses the scheduler (or none for NVMes as they have massive amounts of queues and queue depths and can do that themselves) to reorder them in-flight and commit them, once there's to many, your write OPs will block (i.e., unsurprisingly the kernel doesn't allow every unprivileged process to just take down a machine by triggering some async writes) now with a sync model that means the thread is blocked, with async I can just do something else.
> It's just a bad idea any way you look at it.
Nope, not in our experience; and we heavily evaluated that back when adopting our current design.
But happy to be actually proved wrong, just prototype the fully async multiplexing on top of HTTP/1.1 and let's see if it's faster.
You can either check against our Proxmox Backup Server project directly; it has a benchmark that among other things checks the pure HTTP streaming bandwidth, but we also have a few (a bit dusted) example programs from the very early evaluation time:
an http request can take an unlimited amount of time to complete
the initial response headers can arrive as fast as you like, but the body can be streamed, which can have potentially infinite data, and take potentially infinite time, and it can't be interrupted without terminating the connection altogether
(before you say it: streaming response bodies are in no way abnormal, and can't be dismissed as irrelevant)
as http/1 serializes requests over connections (even with chunking or whatever else) clients cannot in general re-use connections for independent requests for this reason (and others)
if a client makes request A at t=1 and request B at t=2, and request A creates an unbounded length SSE response that lasts until t=999, request B should not need to wait until t=1000 to begin, yet this is what http/1 requires
From where I’m standing QUIC looks like a good contender for a super-TCP like what SCTP never succeeded at becoming. Except there don’t seem to be any (C) libraries with ease of use and lack of inbuilt opinion approaching TCP sockets. (Happy to be proved wrong on that point!) And of course the lack of TLS-less options (outside MsQuic IIUC?) hurts experimentation severely.
Standard posix sockets are mostly just system calls. The TCP state machine is implemented in the OS kernel.
You can switch to raw socket and do the TCP syn/ack dance on your own but this is mostly done for network testing/pen testing, as there are more overhead involved, not less.
This is mostly because the OS actually controls the send/receive buffers used by the actual network drivers. The userland program just takes care of filling these buffers and the kernel and drivers take care of emptying them (i.e. sending). TCP flow control is handled by the kernel, freeing the app to focus on its data. This abstraction actually works quite well.
There are frameworks for userland network stacks, when you're working in high performance networking and need to avoid any overhead the kernel could introduce. The drawback is you need to implement the entire stack, including the low level driver, otherwise it would be slower than what you can already do with classic sockets.
I referred to sockets as an API design, not to express an opinion on whether you should place your protocol implementations inside or outside the kernel. (Although that’s undeniably an interesting question that by all rights should have been settled by now, but isn’t.)
Even then, I didn’t mean you should reproduce the Berkeley socket API verbatim (ZeroMQ-style); multiple streams per connection does not sound like a particularly good fit to it (although apparently people have managed to cram SCTP in there[1]?). I only meant that with the current mainstream libraries[2,3,4], establishing a QUIC connection and transmitting bytestreams or datagrams over it seems quite a bit more involved than performing the equivalent TCP actions using sockets.
Except it obviously does, as demonstrated by many benchmarks on the web. HTTP/2 is faster than HTTP 1.1 for loading resources on a web page.
In real life, browsers open up to four to six HTTP 1.1 connections and maintain them for pipelining. You can increase that number to pretty much anything and enjoy a web full of "permission denied" pages, timeouts and IP bans. I did that for a while when I followed one of those "how to make Firefox faster" guides as a kid, cannot recommend.
That's also four to six three way handshakes, each taking several hundred milliseconds to complete with a risk of failure and retrying, most of which are pretty meaningless, with a hard limit on the amount of individual files one can request at the same time. You'll also have to deal with the traffic congestion engine kicking in multiple times when the WiFi connection degrades. There's also no real way to bypass the TCP slow start for every connection, so you'd better have an excellent connection available or you're artificially restricting your throughput when those streams suddenly start delivering data.
The inline mixing of HTTP/2 removes a whole bunch of restrictions. There are still a bunch of restrictions that only got fixed in HTTP/3 but there's no doubt that HTTP connections improved when HTTP/2 came about.
If a server refuses to process N concurrent requests per second with HTTP/1.1 but happily does so with HTTP/2, the problem lies with the server, not the protocol.
a client making N concurrent HTTP requests to a specific server should not require N discrete connections between the client and the server, it should be able to make those requests over a single connection
request-per-connection is a nice, simple, but ultimately naïve model for network communication
"discrete"? Do you even understand how these networking protocols work?
All a connection is doing is managing the state of a given byte stream, keeping track of how much was sent on one end and received on the other end. All the packets for all connections go through the same pipes and are even routed the same. The TCP stack sees an IP packet coming in, and in its IP and TCP headers it sees it's from IP:port, so it maps it to the state it is maintaining for that source.
HTTP/3 is using UDP, which is inherently connectionless, but is implementing its own logic of multiple streams/connections. It is not doing anything sensibly different.
> All a connection is doing is managing the state of a given byte stream, keeping track of how much was sent on one end and received on the other end. All the packets for all connections go through the same pipes and are even routed the same. The TCP stack sees an IP packet coming in, and in its IP and TCP headers it sees it's from IP:port, so it maps it to the state it is maintaining for that source.
"the state it is maintaining for that source" is the "discrete" thing I'm referring to
creating that state requires at least one network round-trip to the remote, and incurs non-negligible costs on the local machine in the application, network, system, and kernel layers
those costs define a per-connection overhead which are almost immediately the main performance bottleneck in systems that do connection-per-request
those costs amortize to zero if you multiplex requests over a single connection
Http/1 Keep-Alive was one the earliest protocol performance improvement. It meant the TCP connection could be reused for the next resource, avoiding the overhead if closing and reopening a new connection for every request to the same server.
You can see http/2 multiplexing as a natural evolution to the keep alive. Instead of doing every request sequentially, just send everything you need at once and let the server figure out in which order to process everything.
Concurrent TCP connections do have an impact on all stateful firewalls in your path, stateful load balancers and of course the server itself. A client that opens dozens of simultaneous TCP to request all the resources on a page all at once would be frowned upon, and quickly hit rate-limits and anti-abuse protections. You can call it ossification of protocols but that is the situation even google could not workaround when specifying http/2 and then quic.
With HTTP/1.x, if the client wants to make multiple
parallel requests to improve performance, then multiple TCP
connections must be used (see Using Multiple TCP
Connections ). This behavior is a direct consequence of the
HTTP/1.x delivery model, which ensures that only one
response can be delivered at a time (response queuing) per
connection. Worse, this also results in head-of-line
blocking and inefficient use of the underlying TCP
connection.
The new binary framing layer in HTTP/2 removes these
limitations, and enables full request and response
multiplexing, by allowing the client and server to break
down an HTTP message into independent frames, interleave
them, and then reassemble them on the other end.
No, it doesn't. Why do you think they made HTTP/3? Because the whole idea of multiplexing multiple parallel streams onto a single sequential TCP stream is stupid.
As it says in the thing you quoted, the correct approach is to use multiple TCP connections.
The only advantage of HTTP/3 over that is that it only pays for the latency overhead of connection establishment once instead of once per stream. This is a very small optimization that is only relevant in a very narrow set of cases.
probably not it’s usecase, but as a pentester HTTP/3 libraries are a great way to turn unreliable datagram style c2 (udp etc) into a dumb reliable stream for 0 effort ;)
Shame about the minimum MTU otherwise it’d be perfect
HTTP/3 is already widely deployed and most clients use TCP fallback which allows people with an incompatible network to fallback to using an older HTTP version.
>since HTTP/3 is the newer and less common version, it's the version most likely to not work.
Which means those clients will end up using HTTP/2.
>I'm also uncertain about how much HTTP/3 usage there is among the big players like Google, Cloudflare, and so on
Google and Cloudflare have had it for years. Other big players have adopted it too.
Looking outside “desktop” environments the state is still a mess. There are api services using libraries capables of connecting via HTTP/3 but hanging under firewalls or network security appliances that hit that UDP traffic in weird ways. From the outside, you can only expect the complaint from the customer.
It's strange that I had to set up Caddy as a proxy just to connect to a nodejs http server, because setting up Caddy was so much easier than setting up https in nodejs.
But at least it just works for everything I have thrown to it.
That's because node and friends are commonly deployed with tls termination at a load balancer level, and that you likely want a faster server serving up static content (Apache/nginx/caddy/whatever). Given the choice between encouraging people to shoddily wire up TLS in their apps, and providing plug and play support in things like Caddy, I prefer the latter any day of the week!
I don't understand what ,,shoddily wire up'' means. I had to create, maintain and monitor a new service that just to add encryption to my simple web server (actually just to be able to connect to my web server from my browser), that should just be a simple function call.
If everything would be implemented like this, next time leftpad should be a web service on my machine as well?
To be clear, I doubt it was a bug in Caddy. Probably a misconfigured firewall at some point, or a bug with the outdated version of video.js or something.
Basically all I know is:
- Updated from Caddy 2.5.1 to 2.6.2.
- Customer reported video was buffering endlessly.
- Downgraded Caddy to 2.5.1.
- Issue resolved.
But I can file an issue like that if you think it would be helpful.
If it can be reproduced, that'd be helpful. We'd need to know what the client was, what the requests were like, etc. Caddy 2.6 works great with videos from our own testing and production experience.
Try the latest release. Correct implementation was priority 1, then optimization was recently performed by the authors of quic-go. Still more optimizing under way.
It is a must to break existing networking so that TCP bias goes away. It is a big shame only TCP and mostly UDP work while every other protocol is filtered. IP was not designed this way.
Therefore, to reduce pain, it should be inflicted often.
Especially in mobile setups, which are the primary target of QUIC with resumable sessions.
I strongly disagree. HTTP/3 was a google's protocol and they and microsoft used their employees on the IETF to open-wash it. It is designed exclusively for the use cases of corporations and institutions to the detriment to the use cases of human persons. For example, you will not find any implementation of HTTP/3 that allows you to connect to another computer without that computer first getting continual approval from a third party corporation or institution. That is, you can't just connect to a friend's HTTP/3 web server, or your own HTTP/3 server on your LAN with any browser (or otherwise HTTP/3 client) out there. First you have to ask, say, LetsEncrypt for permission.
HTTP/3 is not for human people. It's for corporate people and it will serve them well. But please don't mistake not using HTTP/2 or HTTP/3 with their corporate crap as being backwards. It's the the other way around. I'll be sad when the web dies and all we're left with is Google's centrally controlled QUIC.
Are you saying self signed certificates and custom certificate authorities are banned in HTTP/3? Because as far as I know, there's absolutely nothing stopping you from setting up your own crypto if you don't like certificate authorities.
All current HTTP/3 implementations will not let you use a self-signed cert. Without the CA root it will not connect. The spec for HTTP/3 says this should be the default. There are compile-time flags you can use to enable it but with Google/Microsoft/Apple browsers all not, good luck being able to have people connect to your site.
I'm saying that there is no way for me to distribute and install my custom CA into the browsers of every random person around the globe that will try to visit my website on software defined radio.
I've self-signed my website(s) for 20 years now. In the past it did not matter. But over the last few years I've noticed that actual browser connections are disappearing and all that's left is http bots. They're the only HTTP clients not failing to load my page because of $browsers HTTPS only configuration causing them to see my self-signed cert and thus the browser scaremongering about it causing them to close the tab. HTTP/1.1 going away will be the death of the personal website.
No, most browsers do allow configuring this, but it’s no longer a simple “click through a warning”. Maybe that means the death of the personal website run by someone who refuses to get a certificate which chains to something publicly trusted and compliant with CA/B baselines, but I’d argue that’s actually a good thing — we would obviously disagree on this but I view this as removing easy ways for end users to do insecure things.
Really? Are you sure about that? I'd love to believe you as it'd mean there's been progress on this front but the last time I checked it required compile time flags in Chrome and Firefox. The problem is that this is a function of the libraries these browsers use, it's not an option that is within the browser itself.
>removing easy ways for end users to do insecure things.
That's a legit pov as long as you think about browsers as in the for-profit way: as insecure virtual machines for customers to run your untrusted third party code. And that's certainly the zeitgeist. But that's not what the web is to many human people.
The web of documents still exists despite the last decade of the web just being a mechanism to distribute JS applications. I know that the for-profit point of view doesn't care about the web of documents (not profitable) but that doesn't make their use case the only use case. All you have to do to make accepting self-signed certs as secure (or more secure) than the "normal" web is to turn off automatic execution of untrusted code sent to you. I'd wager that a good fraction of the HN userbase already does this with their NoScript or uBlock or whatever anti-javascript protection extensions.
The ways in which MITM attacks are dangerous are not limited to sites running JavaScript. The big one is that MITM can change what you see on sites. I should be able to trust that everything I read on superkuh.com is your writing, but today anyone operating a network node between my browser and your server can make arbitrary edits to your work.
I agree. But this doesn't matter for the vast majority of websites (ie, non-commercial, non-institutional, personal websites). You can change it so it says or shows whatever and it's not going to hurt anyone. Just like requiring everyone to wear a level 3 bullet proof vest while making dinner will make the process safer, so will requiring CA based certs.
And in this particular exact scenario, you can use my .onion site for superkuh.com to verify the end-point identity if you're really worried that someone might change the text. A system that works without CAs.
For public facing things this is likely good. For my own home use it is quite an annoyance.
The thing I wonder: will this prevent Internet of Sh*t devices to spread or will they become fully reliant on cloud, thus dependent on the vendor (as the customer's browser won't talk to it)
> HTTP/1.1 going away will be the death of the personal website.
How does requiring HTTPS turn into no more personal websites? Let's Encrypt offers free certificates with automated renewal and minimal hassle, and if you don't like them there are several free alternatives.
First is the obvious increase in complexity and fragility of websites requiring re-approval every 90 (or whatever) days. A personal website made of .html and other files in the past would last, literally forever. Now require HTTPS and ACME(1/2/whatever) based re-approval and at some point that complex stack of software (who's complexity is hidden from the user) will break. The website will become inaccessible and die. And not only does it make them more fragile but it makes setting up a website for the first time much more complex.
The second is more abstract but notice how literally everyone in this thread is recommending LetsEncrypt. That's great, and I love LE and I'm really glad they exist. But this is literally putting all our eggs in one basket. The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites. Like, say, a website for an abortion clinic that is now against the law in Texas. Switching to comodo when this happens won't fix it.
> A personal website made of .html and other files in the past would last, literally forever.
Web serving has always had moving parts, and there has always been some maintenance required to keep sites up. I agree that HTTPS increases the burden here, but not from zero.
> at some point that complex stack of software (who's complexity is hidden from the user) will break
Sort of? People definitely screw up their HTTPS configuration from time to time, or run into bugs. But the acme software is very reliable, so this is rare, and if it does happen blowing your existing configuration away and starting fresh will fix it.
> And not only does it make them more fragile but it makes setting up a website for the first time much more complex.
If you want to set up a website with minimal steps you generally get someone else to host, at which point they are dealing with HTTPS. If you want to do it all yourself HTTPS does add a step, but it is small compared to all of the other steps involved in setting up a server.
> The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites.
The US legal system cannot currently compel Let's Encrypt to refuse service to lawbreaking sites, and even if the law changed here you could get a certificate from a CA in another country.
acme hasn't even been around long enough to be called reliable. Imagine a website set up in 2017 using acme 1 protocol. That website is now dead because acme 1 is no longer supported; only acme 2.
You need to renew your domain every year. You need to either pay your hosting provider or, in the case of hardware you run yourself, your ISP providing network connectivity, on a regular basis. How is relying on a third-party for certificates any different?
And you do understand the reason why having browsers verify that they're actually talking to who they think they're talking to is important, right?
Nope. I can and have used my IP address. I host from the computer sitting 1 meter to my left in my apartment. I have for 20+ years. It's just as easy to send http://73.5.160.29/somefunnypic.jpg as http://superkuh.com/somefunnypic.jpg on IRC, or in email, or whatever if it comes to that. Plus there are overlay networks like Tor that I use that do provide end-point identity verification that work great without a centralized domain or CA system.
This doesn't really seem like a real issue. By eschewing domain names, you've already killed any chance of a mainstream audience for the site. That's fine, but it's also not particularly complicated for the users to support an alternative protocol where you don't need TLS if it's already so niche.
> By eschewing domain names, you've already killed any chance of a mainstream audience for the site. That's fine, but it's also not particularly complicated for the users to support an alternative protocol where you don't need TLS if it's already so niche.
These are very different. If need to convince your audience to get and install some alternate client with an alternate protocol, now you audience it at best only a few techies who can do that for themselves.
Whereas sending anyone an URL they can click on with any client, even if it identified by an IP address instead of a hostname, is as easy at it gets.
> How does requiring HTTPS turn into no more personal websites?
Let's Encrypt is awesome, I use them for all my personal sites (web and non).
Threat modeling covers more than just authenticity and confidentiality. For instance, denial of service is also something to evaluate. So why does this matter?
Today if Let's Encrypt suddenly disappears or goes evil and no longer wants to issue me a certificate, I can simply re-enable plan HTTP on my site and my content remains available. Sure there are drawbacks but there are pros and cons to everything. As a static site I'm comfortable with the cons of hosting it via HTTP if the only alternative is not being able to host at all. Important things is I can make that choice.
In a world where normal people (i.e. non-techies who can't be expected to build their own browsers from source or whatever) can only have access to a client that enforces public CA issued certificates, it becomes easier than ever to drop unwelcome people effectively off the internet.
And in fact you can do this almost automatically the next time you upgrade your webserver to resolve security issues. It's about as easy as it can get, easier than a lot of things people do every week (shopping, etc).
If you think an acme using website is going to remain accessible when left unattended for a decade I have a bridge to sell you. acme 1 didn't even last a handful of years. And that's ignoring the dozens of ways every individual acme package can and do fail even before the protocol becomes obsoleted. Moving parts break. Even if the complexity is hidden from you it is still there. And lets not even get into root cert churn. Remember when LE's original root cert stopped working a couple years ago?
HTTPS only, CA TLS only, leads to websites with lifetimes that max out around several years. This is fine for corporate/institutions as nothing of theirs lasts this long anyway. But it's a huge problem with personal sites which remain useful and valuable for longer time periods.
It doesn't need to last a decade no more than does a web server. We have to upgrade software, it's just a fact of life. I don't really understand the objection on those grounds. It sounds like you just don't want to do it for other reasons.
I can't find much about this in the HTTP/3 spec. Validation of certificates must be done according to section 4.3.4 of RFC9110 which explicitly spells out that browsers must either get permission to continue or abort, but that's up to the browser to decide.
I can find some references to Chrome's QUIC not supporting self signed certificates, but I can't find any source that says that WebKit and Firefox made the same decision. Do you happen to know a self signed HTTP/3 URL that I can test this with?
Browsers choosing to break self signed certificates can happen even with HTTP 0.9. All they need to do is require the user to type the bypass phrase ("thisisunsafe" in the Chrome error screen) on any certificate validation error and enable HTTPS only mode. This has nothing to do with spec. Browsers have even removed spec implementations for HTTP/2 spec (HTTP push) after a few years.
The problems you described are specific to implementations, not the protocol itself. I have read all of the QUIC specs in full (since I'm working on an implementation) and have seen nothing in any of them that mandates a centralised certificate infrastructure (caveat: I have not read the HTTP/3 spec, perhaps you could point out the relevant section if its in there). Of course, the most common use case requires this, but in that respect it's no different to HTTPS.
IPFS uses QUIC as one of its supported transport protocols, and this works in the most common implementation, Kubo [1]. The spec for the QUIC transport used in IPFS [2] indicates the same certificate trust policy as for the TLS protocol [3]. The latter, in turn, relies on peer-to-peer authentication with automatically-generated self-signed certificates containing a libp2p-specific additional extension.
IPFS is particularly well suited to the use case of personal websites you've mentioned, as it's specifically designed to operate without any form of centralisation.
Only bad or new software developers update software. Pin your dependencies, don't use new protocols, Snow Leopard was the last good macOS version. Library doesn't work on the newest Node or Python version? Who cares, it's only been out for half a year who's even using it yet? Some people spent hundreds of hours making something better, why would you want to use the result?
This university seems to be the exact reason why network protocols are stuck in their terrible 80s designs.
They've set up an incredibly restrictive systems of firewalls and networks, making it super hard for themselves to upgrade their own network or adapt to the world around them.
Then they write a big post about how much work allowing UDP/443 through their network supposedly is, proving that they not only already blocked tons of legitimate traffic (OpenVPN over 443 is super common) but also that apparently their setup is set up in a way that's impossible for them to manage.
They're running some kind of firewall system that's analysing people's traffic and they're afraid HTTP/3 will put a stop to that. That means either their tooling isn't maintained well enough or they employ some kind of sketchy trickery to get the older protocols to play "nice" with their data collection.
They implore others to please stick to the protocols of the past so they don't need to change their network in the future.
This university acts like the worst ISP imaginable. Who even uses a whitelist for outgoing ports anymore? Block whatever stupid protocols Windows uses for file sharing so you don't leak your credentials, that's all the outgoing filtering you need. If I were a student or an employee there, I would make sure that every single but leaving my devices is going through some kind of encrypted VPN, though I'm sure they'll try their hardest to block that too. Universities are research facilities, they're supposed to be at the forefront of technology, not run into service issues because their policies are frozen in the late 90s.
When HTTP/3 hits the common software packages, I'll be turning it on on all of my services purely out of spite against institutions and companies like this. If your network can't deal with industry standards, it deserves all the shame and support tickets it'll generate.
I think you're confused about the context in which they are not yet supporting HTTP/3: they are deciding to hold off on serving it, not on allowing it to pass through their network:
All of this is of course academic until Ubuntu's version of Apache supports HTTP/3. We're quite unlikely to switch web servers to get HTTP/3
They're worried some of their users will be in environments that don't properly support QUIC, and if they started serving HTTP/3 today they might have more support hassle.
If you click the link in the blog post with the text “firewalls need adjustments to let 'QUIC' traffic through”, it seems like there is some of the latter as well. Well, not holding off on allowing it through their network, per se, but being worried that their overly complex firewall setup hasn’t been properly adjusted to allow it through their network in all cases.
I would've accepted that train of thought if it wasn't for their earlier posts about how HTTP/3 is making their lives more difficult. I don't know what's happening to their firewall, but these people seem to run into HTTP/3 problems all the time. There's a difference between "I'm not switching to electric cars yet" and "I'm not switching to electric cars yet after I've burned down my house three times installing electric chargers".
Their network is somehow horribly broken and that leads them to pain a picture as if the protocol is somehow inherently stable or problematic to turn on. They're projecting their own misconfiguration onto the wider internet as a whole, and this is exactly the kind of behaviour that has led to the protocol ossification we see today.
I think they must've stopped blocking HTTP/3 at some point because the author has had other HTTP/3 related issues they posted about since. However, as of this post: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/WireGuardF... I think it's still safe to consider their network setup hasn't changed much.
A lot of modern TCP tweaks have been added over the years to make the protocol faster and better. We're long past the Reno algorithm and ethernet CSMA sensing taught in textbooks, despite much of the protocol remaining seemingly unchanged.
Personally, I'd much rather have seen SCTP get picked up than QUIC for solving the HTTP/3 problem, but we need to wrap modern protocols in 1980's UDP or risk networks dropping the traffic for no good reason. TLS 1.3 had to be written in a specific way to look like TLS 1.2 or middleboxes everywhere would throw a fit.
Some old protocols used are used because they Just Work, (most of) NTP is a clear demonstration of that. However, many other protocols are still in use simply because rolling out alternatives isn't feasible.
> When HTTP/3 hits the common software packages, I'll be turning it on on all of my services purely out of spite against institutions and companies like this. If your network can't deal with industry standards, it deserves all the shame and support tickets it'll generate.
You should probably spend some time understanding these environments before giving in to such hostility for your peers.
I've spent most of the last 20 years supporting users and systems in higher education environments. Universities are class environments, research facilities, mid size enterprises and residential environments ALL IN ONE. I'm sure there are some with open positions if you're willing take a shot at supporting all of that with a budget that covers less and less every year. Good luck staying at the forefront of technology.
I feel for the people working in these environments, I really do, because most of them didn't choose to get stuck with an outdated network topology. They have to make do. I don't blame any specific person for the situation an institution or company is in.
However, as an institution, the university should still remain at the forefront. Whether their network can't keep up because of a lack of funding, bad management decisions, or other factors doesn't really matter.
These tickets and questions aren't punishment for bad management, they're a signal that an overhaul (and the accompanying funding) is necessary. Migration plans need to be made, plans need to be written down, a lot of work is going to need doing, and without any signals that the system can't keep up you're not going to get anyone to sign off on such grandiose plans.
Maybe that won't be enough, maybe the network is doomed to survive only by constant patching and emergency fixes until the staff is driven mad and quits, but that's no reason for others to slow down the rollout of modern network protocols.
I look forward to being blocked by you, lol. My network devices have a convenient option already to block all QUIC traffic, and it is one of the settings I immediately sought out. (We also block VPNs where I work, generally.)
Network management is there for a purpose, and the people focusing on bypassing it are generally bad actors. The authors of HTTP/2 and HTTP/3 are more focused on guaranteeing delivery of ads than being able to block malicious activity.
Rest easy, HTTP/3 and below have fallback mechanisms all the way back to HTTP 1.0, as long as you still keep TLS enabled. I'm not planning on blocking anything older than TLS 1.2 in my standard config.
I fully support user choice to disable whatever protocol they want. I also think modern browsers lack options in this department. If you dislike QUIC, which I can completely understand, you should disable it.
On the server side, though, you can use modern servers and tell all your clients to stick with HTTP 1.1. Let the people who do like QUIC (or don't care) get the benefit of faster page loads and lower latency. HTTP/2 and HTTP/3 solve some real performance issues, particularly for users with unstable or slow internet connections. I don't see why would would deprive them of that simply because you prefer to have the protocol disabled.
> Block whatever stupid protocols Windows uses for file sharing so you don't leak your credentials, that's all the outgoing filtering you need.
It's clear that you've never managed networks that need to meet stringent security requirements.
> Universities are research facilities, they're supposed to be at the forefront of technology, not run into service issues because their policies are frozen in the late 90s.
It's also clear that you've never worked on infrastructure in a large heterogenous environment that grew organically over decades. Or dealt with infrastructure that was grant funded.
Yeah both of those problems are solved or alleviated with tooling but it can take years to get all the disparate systems managed in house.
This is about a university, not the NSA. Sure, there are other security measures you need to take (known botnets etc.) but a blanket ban on all outgoing network traffic? That's just excessive.
This isn't the first post the author has made about their university's network infrastructure. The HTTP/3 issues start being named years back.
The university, as an organisation, doesn't seem to want to move away from the old way of doing networking. There's no indication this is a "we have to hotfix it for now because our new systems are done in 2030" network, and every indication that they're stretching their current design for as long as it'll hold.
Even if they're doing this for security reasons, the days of unsecured bastions with a strict firewall around them, as suggested by their latest infrastructure blog post, are long gone. I highly doubt security is the reason the university can't move on.
With no migration plans as far as I can see, they're setting themselves up for failure again when HTTP/4 inevitably comes around, or when strict networking peculiarities cause the next QUIC/HTTP3/TLS 1.3 bug the author will have to dive into and figure out.
> that need to meet stringent security requirements
That need to meet overreaching legal compliance requirements, maybe, but this isn't the same as security.
> you've never worked on infrastructure in a large heterogenous environment that grew organically over decades. Or dealt with infrastructure that was grant funded.
I should hope you don't need to be an outsider/inexperienced to point out obvious dysfunction. Yes, said dysfunction almost always has very explainable context and causes (organic growth over decades, inconsistent/dependent funding structures, etc.) but neither negate the fact that it is a form of dysfunction, nor should they put it beyond criticism (from inside or out).
Blocking random VPN traffic is one of the very first things you do when securing/managing a network. Letting any random device create a split tunnel anywhere is _insane_ .
Just because some guys out west had an idea and therefore it's the "new thing" doesn't mean that it the right thing for everyone.
This reminds me of secondary school, where the IT guy blocked UDP completely. WireGuard didn't work, HTTP3/QUIC didn't work, network time didn't work, and probably a bunch of other stuff.
This is perfectly reasonable if you provide internal network time, and you don't want people using your network for illegal activity. At work we don't block "all UDP", but we block anything QUIC, anything classified as a VPN or proxy, and anything like DoH which is intended to obscure visibility into network usage.
Organizations who are not doing this are not adequately managing their network.
Isn't it kind of creepy that you manage which websites people can visit and spy on their usage? I disagree that this is needed for "adequately managing their network."
Generally we don't monitor activity, we just filter it. As I say "I'm an engineer, not the HR department". But there's significant legal and reputational risk to not preventing illegal activity from your network, and major security risks to not blocking malicious content from things like ad companies. Unsurprisingly, the lead pusher of HTTP/3 and QUIC is the world's most pervasive ad company.
121 comments
[ 3.1 ms ] story [ 148 ms ] threadReaching http3 servers outside those networks is indeed not a problem as the connection gets downgraded appropriately. You'd know this when Google, for example, stops working inside your network as most of their load balancers are serving http3. Users tend to complain about these things and this obviously hasn't been happening. Ergo, connections are being downgraded as you'd expect.
But putting up webservers serving http3 in a network that blocks udp3 is indeed not going to work until somebody fixes the firewall. You could still do it and test if browsers from outside the network downgrade correctly. But that seems a bit pointless.
Would be interesting to see how many will requests get downgraded or not over a long period of time.
I’d love to have more rigorous analysis of what tricks are pulled, and how those can be addressed from first principles. I’ve yet to see such a take, but that’s understandable, because all this institutional knowledge is spread across segmented information islands.
I was just lamenting a couple days ago about the email templates written in tables and HTML4 Transitional. It’s 2023, wtf.
https://demo.react.email/preview/nike-receipt doesn't seem that bad
Inline styling and tables, instead of semantic HTML5 and a style block.
Neither are particularly useful unless you're a web browser. I'm sticking to HTTP/1.1 myself in all of my code.
Funnily enough most engineers don't seem to have any idea how TCP works these days.
> HTTP/2 is bad because XYZ, HTTP 3 at least fixes Z
Note giving reasons, and preferably also reasoning behind those reasons. You know, the "arguments"
Here is what clown riding that dunning-kruger peak thinks that "argument" is:
> HTTP/2 is just plain silly, HTTP/3 is a silly idea but implemented correctly.
We also plan to closer evaluate HTTP/3 (h3) soon, mainly to see how the promised improvements, like no head of line blocking, turn out in practice for our use case.
So I'd disagree that h2 or h3 is useless "unless you're a web browser"; but sure if you use HTTP only to provide a simple text (e.g., JSON) based API it might not be _that_ relevant. But some benefits like faster TLS setup might even make a difference there, e.g., faster initial startup, fewer packets transmitted, IIRC even packet sniffing should be a bit harder to do with h3. If those benefits are worth it on its own, depends then probably on how easy it's to integrate in your project, iow., if your framework/standard lib/ecosystem/... already supports h3 nicely. We use the rust hyper crate for most of our HTTP* communication, and their h3 implementation is still marked as experimental; and as we're not in a rush we'll just wait until the hyper project stabilizes h3.
What HTTP 2 does is that it makes it possible to send multiple responses in parallel instead of one after each other.
Chunked transfer isn't the issue, I know that would be easily dooable with h1.1, but it would be one serialized & sync stream.
All you're doing is reducing the latency of the first request.
But yeah on package loss there's head of line blocking, which http 3 solves by using UDP and handling the reliability on the higher level.
Your thread is spending its time waiting for the other end to ack before it can send more data, delaying any other kind of work your thread has to do (such as serving other clients). The rate at which it can write doesn't magically increase by attempting to write multiple streams concurrently; quite the opposite. The rate is controlled by the other end, and what you should do if you implement a high-performance TCP service (HTTP or not) is simply disconnect clients that require you to ever block.
Now you could say, "I don't care, I write the data asynchronously". Asynchronous writes are very bad and an anti-pattern, they should typically never be used because they mean you are just queueing data indefinitely until it is eventually written, wasting massive amounts of RAM (if not taking the machine down entirely). Queues in general are serious business and require a careful design to ensure the producer doesn't produce data faster than the consumer, with adequate back-pressure algorithms. It is better to keep track of when you can write and decide on how to handle not being able to write rather than block or queue like an idiot.
Multiplexing with HTTP/2 logically makes the TCP stream which is logically a spsc queue into a pseudo-mpsc queue. Those are also way more difficult to reason about to guarantee fairness and back-pressure, they're pretty much a bottleneck by design. It's just a bad idea any way you look at it.
> TCP must send all data in order. To implement that, all data sent out gets written to a retransmit buffer (which may be dynamically sized, but only up to a maximum).
To a send buffer, at least that's what most TCP implementation name it and with modern surprisingly high reliable networks it's mostly used for that. But yes, again (3rd time now), this is head-of-line blocking which HTTP/3 would solve (and which you also classified as being just useful for web browsers, whatever that even means).
More important, yes while TCP is in-order and if the network is slow and/or drops a lot of packets you will notice that, BUT it can batch multiple HTTP requests into single TCP package and that's why an async concurrent or even parallel application can benefit from using it directly.
> Your thread is spending its time waiting for the other end to ack before it can send more data, delaying any other kind of work your thread has to do (such as serving other clients).
No it doesn't, as we are fully async on all layers with rust's zero-cost async model, e.g. using the async tokio rust crate, it can just continue to handle other requests.
Also, what would change here by using HTTP/1.1? It has the same limitations as it also uses TCP, but additionally can't batch multiple requests into single TCP packets is text based (bad for binary data) and has additional down sites - e.g., slow on start up.
> Now you could say, "I don't care, I write the data asynchronously". Asynchronous writes are very bad and an anti-pattern, they should typically never be used because they mean you are just queueing data indefinitely until it is eventually written, wasting massive amounts of RAM (if not taking the machine down entirely).
Note that 1) we're talking mostly about reads here, and 2) async writes where never that bad and especially nowadays we're not in the spinning-rust-HDDs-only era anymore, so I'd recommend getting that rather dated and never quite right view updated. How would async writes even take down a machine? The kernel just uses the scheduler (or none for NVMes as they have massive amounts of queues and queue depths and can do that themselves) to reorder them in-flight and commit them, once there's to many, your write OPs will block (i.e., unsurprisingly the kernel doesn't allow every unprivileged process to just take down a machine by triggering some async writes) now with a sync model that means the thread is blocked, with async I can just do something else.
> It's just a bad idea any way you look at it.
Nope, not in our experience; and we heavily evaluated that back when adopting our current design. But happy to be actually proved wrong, just prototype the fully async multiplexing on top of HTTP/1.1 and let's see if it's faster. You can either check against our Proxmox Backup Server project directly; it has a benchmark that among other things checks the pure HTTP streaming bandwidth, but we also have a few (a bit dusted) example programs from the very early evaluation time:
https://git.proxmox.com/?p=proxmox-backup.git;a=tree;f=examp...
the initial response headers can arrive as fast as you like, but the body can be streamed, which can have potentially infinite data, and take potentially infinite time, and it can't be interrupted without terminating the connection altogether
(before you say it: streaming response bodies are in no way abnormal, and can't be dismissed as irrelevant)
as http/1 serializes requests over connections (even with chunking or whatever else) clients cannot in general re-use connections for independent requests for this reason (and others)
if a client makes request A at t=1 and request B at t=2, and request A creates an unbounded length SSE response that lasts until t=999, request B should not need to wait until t=1000 to begin, yet this is what http/1 requires
You can switch to raw socket and do the TCP syn/ack dance on your own but this is mostly done for network testing/pen testing, as there are more overhead involved, not less.
This is mostly because the OS actually controls the send/receive buffers used by the actual network drivers. The userland program just takes care of filling these buffers and the kernel and drivers take care of emptying them (i.e. sending). TCP flow control is handled by the kernel, freeing the app to focus on its data. This abstraction actually works quite well.
There are frameworks for userland network stacks, when you're working in high performance networking and need to avoid any overhead the kernel could introduce. The drawback is you need to implement the entire stack, including the low level driver, otherwise it would be slower than what you can already do with classic sockets.
Even then, I didn’t mean you should reproduce the Berkeley socket API verbatim (ZeroMQ-style); multiple streams per connection does not sound like a particularly good fit to it (although apparently people have managed to cram SCTP in there[1]?). I only meant that with the current mainstream libraries[2,3,4], establishing a QUIC connection and transmitting bytestreams or datagrams over it seems quite a bit more involved than performing the equivalent TCP actions using sockets.
[1] https://datatracker.ietf.org/doc/html/rfc6458
[2] https://quiche.googlesource.com/quiche
[3] https://github.com/microsoft/msquic
[4] https://github.com/litespeedtech/lsquic
most often, it helps when there are multiple logical connections muxed over a single physical connection
In real life, browsers open up to four to six HTTP 1.1 connections and maintain them for pipelining. You can increase that number to pretty much anything and enjoy a web full of "permission denied" pages, timeouts and IP bans. I did that for a while when I followed one of those "how to make Firefox faster" guides as a kid, cannot recommend.
That's also four to six three way handshakes, each taking several hundred milliseconds to complete with a risk of failure and retrying, most of which are pretty meaningless, with a hard limit on the amount of individual files one can request at the same time. You'll also have to deal with the traffic congestion engine kicking in multiple times when the WiFi connection degrades. There's also no real way to bypass the TCP slow start for every connection, so you'd better have an excellent connection available or you're artificially restricting your throughput when those streams suddenly start delivering data.
The inline mixing of HTTP/2 removes a whole bunch of restrictions. There are still a bunch of restrictions that only got fixed in HTTP/3 but there's no doubt that HTTP connections improved when HTTP/2 came about.
request-per-connection is a nice, simple, but ultimately naïve model for network communication
All a connection is doing is managing the state of a given byte stream, keeping track of how much was sent on one end and received on the other end. All the packets for all connections go through the same pipes and are even routed the same. The TCP stack sees an IP packet coming in, and in its IP and TCP headers it sees it's from IP:port, so it maps it to the state it is maintaining for that source.
HTTP/3 is using UDP, which is inherently connectionless, but is implementing its own logic of multiple streams/connections. It is not doing anything sensibly different.
"the state it is maintaining for that source" is the "discrete" thing I'm referring to
creating that state requires at least one network round-trip to the remote, and incurs non-negligible costs on the local machine in the application, network, system, and kernel layers
those costs define a per-connection overhead which are almost immediately the main performance bottleneck in systems that do connection-per-request
those costs amortize to zero if you multiplex requests over a single connection
Http/1 Keep-Alive was one the earliest protocol performance improvement. It meant the TCP connection could be reused for the next resource, avoiding the overhead if closing and reopening a new connection for every request to the same server.
You can see http/2 multiplexing as a natural evolution to the keep alive. Instead of doing every request sequentially, just send everything you need at once and let the server figure out in which order to process everything.
Concurrent TCP connections do have an impact on all stateful firewalls in your path, stateful load balancers and of course the server itself. A client that opens dozens of simultaneous TCP to request all the resources on a page all at once would be frowned upon, and quickly hit rate-limits and anti-abuse protections. You can call it ossification of protocols but that is the situation even google could not workaround when specifying http/2 and then quic.
Probably they are referring to head of line blocking: https://en.wikipedia.org/wiki/Head-of-line_blocking
But I suppose it's common for web people to have no idea how networking actually works.
https://web.dev/performance-http2/
it very often makes sense "to do that"As it says in the thing you quoted, the correct approach is to use multiple TCP connections.
The only advantage of HTTP/3 over that is that it only pays for the latency overhead of connection establishment once instead of once per stream. This is a very small optimization that is only relevant in a very narrow set of cases.
making 10 concurrent HTTP GET requests to the same server should not require you to make 10 connections to that server
muxing multiple logical connections/streams over a single physical connection is, like, networking 101 type stuff
you're out of your element donny, go home
there's plenty to criticize about HTTP/2 and HTTP/3 but they're definitely beneficial in many circumstances
Shame about the minimum MTU otherwise it’d be perfect
>since HTTP/3 is the newer and less common version, it's the version most likely to not work.
Which means those clients will end up using HTTP/2.
>I'm also uncertain about how much HTTP/3 usage there is among the big players like Google, Cloudflare, and so on
Google and Cloudflare have had it for years. Other big players have adopted it too.
An interesting usage from Wikimedia: https://www.usenix.org/sites/default/files/conference/protec...
But at least it just works for everything I have thrown to it.
If everything would be implemented like this, next time leftpad should be a web service on my machine as well?
Basically all I know is:
- Updated from Caddy 2.5.1 to 2.6.2.
- Customer reported video was buffering endlessly.
- Downgraded Caddy to 2.5.1.
- Issue resolved.
But I can file an issue like that if you think it would be helpful.
Therefore, to reduce pain, it should be inflicted often.
Especially in mobile setups, which are the primary target of QUIC with resumable sessions.
Corporate networks are not the Internet.
This blog post itself served from HTTP/1.1 and IPv4 for me.
I guess the improving internet is handed over to the big companies who benefit them.
They have no incentive to hold backward compatibility and putting smaller websites offline
HTTP/3 is not for human people. It's for corporate people and it will serve them well. But please don't mistake not using HTTP/2 or HTTP/3 with their corporate crap as being backwards. It's the the other way around. I'll be sad when the web dies and all we're left with is Google's centrally controlled QUIC.
I'm saying that there is no way for me to distribute and install my custom CA into the browsers of every random person around the globe that will try to visit my website on software defined radio.
I've self-signed my website(s) for 20 years now. In the past it did not matter. But over the last few years I've noticed that actual browser connections are disappearing and all that's left is http bots. They're the only HTTP clients not failing to load my page because of $browsers HTTPS only configuration causing them to see my self-signed cert and thus the browser scaremongering about it causing them to close the tab. HTTP/1.1 going away will be the death of the personal website.
Really? Are you sure about that? I'd love to believe you as it'd mean there's been progress on this front but the last time I checked it required compile time flags in Chrome and Firefox. The problem is that this is a function of the libraries these browsers use, it's not an option that is within the browser itself.
>removing easy ways for end users to do insecure things.
That's a legit pov as long as you think about browsers as in the for-profit way: as insecure virtual machines for customers to run your untrusted third party code. And that's certainly the zeitgeist. But that's not what the web is to many human people.
The web of documents still exists despite the last decade of the web just being a mechanism to distribute JS applications. I know that the for-profit point of view doesn't care about the web of documents (not profitable) but that doesn't make their use case the only use case. All you have to do to make accepting self-signed certs as secure (or more secure) than the "normal" web is to turn off automatic execution of untrusted code sent to you. I'd wager that a good fraction of the HN userbase already does this with their NoScript or uBlock or whatever anti-javascript protection extensions.
And in this particular exact scenario, you can use my .onion site for superkuh.com to verify the end-point identity if you're really worried that someone might change the text. A system that works without CAs.
Among other things a MitM can:
- insert ads in your page
- run miners on your user's browser
- change links or redirect the page (likely to an CA-signed malware site)
- insert malware in downloadable scripts on your site (http://superkuh.com/TkTTS.pl)
Software\Policies\Google\Chrome,SSLErrorOverrideAllowed,REG_DWORD,1
The thing I wonder: will this prevent Internet of Sh*t devices to spread or will they become fully reliant on cloud, thus dependent on the vendor (as the customer's browser won't talk to it)
How does requiring HTTPS turn into no more personal websites? Let's Encrypt offers free certificates with automated renewal and minimal hassle, and if you don't like them there are several free alternatives.
The second is more abstract but notice how literally everyone in this thread is recommending LetsEncrypt. That's great, and I love LE and I'm really glad they exist. But this is literally putting all our eggs in one basket. The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites. Like, say, a website for an abortion clinic that is now against the law in Texas. Switching to comodo when this happens won't fix it.
Web serving has always had moving parts, and there has always been some maintenance required to keep sites up. I agree that HTTPS increases the burden here, but not from zero.
> at some point that complex stack of software (who's complexity is hidden from the user) will break
Sort of? People definitely screw up their HTTPS configuration from time to time, or run into bugs. But the acme software is very reliable, so this is rare, and if it does happen blowing your existing configuration away and starting fresh will fix it.
> And not only does it make them more fragile but it makes setting up a website for the first time much more complex.
If you want to set up a website with minimal steps you generally get someone else to host, at which point they are dealing with HTTPS. If you want to do it all yourself HTTPS does add a step, but it is small compared to all of the other steps involved in setting up a server.
> The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites.
The US legal system cannot currently compel Let's Encrypt to refuse service to lawbreaking sites, and even if the law changed here you could get a certificate from a CA in another country.
And you do understand the reason why having browsers verify that they're actually talking to who they think they're talking to is important, right?
HTTP/3 would break this.
These are very different. If need to convince your audience to get and install some alternate client with an alternate protocol, now you audience it at best only a few techies who can do that for themselves.
Whereas sending anyone an URL they can click on with any client, even if it identified by an IP address instead of a hostname, is as easy at it gets.
Let's Encrypt is awesome, I use them for all my personal sites (web and non).
Threat modeling covers more than just authenticity and confidentiality. For instance, denial of service is also something to evaluate. So why does this matter?
Today if Let's Encrypt suddenly disappears or goes evil and no longer wants to issue me a certificate, I can simply re-enable plan HTTP on my site and my content remains available. Sure there are drawbacks but there are pros and cons to everything. As a static site I'm comfortable with the cons of hosting it via HTTP if the only alternative is not being able to host at all. Important things is I can make that choice.
In a world where normal people (i.e. non-techies who can't be expected to build their own browsers from source or whatever) can only have access to a client that enforces public CA issued certificates, it becomes easier than ever to drop unwelcome people effectively off the internet.
HTTPS only, CA TLS only, leads to websites with lifetimes that max out around several years. This is fine for corporate/institutions as nothing of theirs lasts this long anyway. But it's a huge problem with personal sites which remain useful and valuable for longer time periods.
I can find some references to Chrome's QUIC not supporting self signed certificates, but I can't find any source that says that WebKit and Firefox made the same decision. Do you happen to know a self signed HTTP/3 URL that I can test this with?
Browsers choosing to break self signed certificates can happen even with HTTP 0.9. All they need to do is require the user to type the bypass phrase ("thisisunsafe" in the Chrome error screen) on any certificate validation error and enable HTTPS only mode. This has nothing to do with spec. Browsers have even removed spec implementations for HTTP/2 spec (HTTP push) after a few years.
IPFS uses QUIC as one of its supported transport protocols, and this works in the most common implementation, Kubo [1]. The spec for the QUIC transport used in IPFS [2] indicates the same certificate trust policy as for the TLS protocol [3]. The latter, in turn, relies on peer-to-peer authentication with automatically-generated self-signed certificates containing a libp2p-specific additional extension.
IPFS is particularly well suited to the use case of personal websites you've mentioned, as it's specifically designed to operate without any form of centralisation.
[1] https://github.com/ipfs/kubo.
[2] https://github.com/libp2p/specs/tree/master/quic
[3] https://github.com/libp2p/specs/blob/master/tls/tls.md
Your basic test case of a web browser being able to do ChaCha-HTTP/2-only is simply to visit https://egbert.net/ and successfully get a web page.
They've set up an incredibly restrictive systems of firewalls and networks, making it super hard for themselves to upgrade their own network or adapt to the world around them.
Then they write a big post about how much work allowing UDP/443 through their network supposedly is, proving that they not only already blocked tons of legitimate traffic (OpenVPN over 443 is super common) but also that apparently their setup is set up in a way that's impossible for them to manage.
They're running some kind of firewall system that's analysing people's traffic and they're afraid HTTP/3 will put a stop to that. That means either their tooling isn't maintained well enough or they employ some kind of sketchy trickery to get the older protocols to play "nice" with their data collection.
They implore others to please stick to the protocols of the past so they don't need to change their network in the future.
This university acts like the worst ISP imaginable. Who even uses a whitelist for outgoing ports anymore? Block whatever stupid protocols Windows uses for file sharing so you don't leak your credentials, that's all the outgoing filtering you need. If I were a student or an employee there, I would make sure that every single but leaving my devices is going through some kind of encrypted VPN, though I'm sure they'll try their hardest to block that too. Universities are research facilities, they're supposed to be at the forefront of technology, not run into service issues because their policies are frozen in the late 90s.
When HTTP/3 hits the common software packages, I'll be turning it on on all of my services purely out of spite against institutions and companies like this. If your network can't deal with industry standards, it deserves all the shame and support tickets it'll generate.
All of this is of course academic until Ubuntu's version of Apache supports HTTP/3. We're quite unlikely to switch web servers to get HTTP/3
They're worried some of their users will be in environments that don't properly support QUIC, and if they started serving HTTP/3 today they might have more support hassle.
Their network is somehow horribly broken and that leads them to pain a picture as if the protocol is somehow inherently stable or problematic to turn on. They're projecting their own misconfiguration onto the wider internet as a whole, and this is exactly the kind of behaviour that has led to the protocol ossification we see today.
I think that post is much less reasonable, but it's also almost 2 years old and they may not be doing that kind of blocking anymore?
Personally, I'd much rather have seen SCTP get picked up than QUIC for solving the HTTP/3 problem, but we need to wrap modern protocols in 1980's UDP or risk networks dropping the traffic for no good reason. TLS 1.3 had to be written in a specific way to look like TLS 1.2 or middleboxes everywhere would throw a fit.
Some old protocols used are used because they Just Work, (most of) NTP is a clear demonstration of that. However, many other protocols are still in use simply because rolling out alternatives isn't feasible.
You should probably spend some time understanding these environments before giving in to such hostility for your peers.
I've spent most of the last 20 years supporting users and systems in higher education environments. Universities are class environments, research facilities, mid size enterprises and residential environments ALL IN ONE. I'm sure there are some with open positions if you're willing take a shot at supporting all of that with a budget that covers less and less every year. Good luck staying at the forefront of technology.
However, as an institution, the university should still remain at the forefront. Whether their network can't keep up because of a lack of funding, bad management decisions, or other factors doesn't really matter.
These tickets and questions aren't punishment for bad management, they're a signal that an overhaul (and the accompanying funding) is necessary. Migration plans need to be made, plans need to be written down, a lot of work is going to need doing, and without any signals that the system can't keep up you're not going to get anyone to sign off on such grandiose plans.
Maybe that won't be enough, maybe the network is doomed to survive only by constant patching and emergency fixes until the staff is driven mad and quits, but that's no reason for others to slow down the rollout of modern network protocols.
Network management is there for a purpose, and the people focusing on bypassing it are generally bad actors. The authors of HTTP/2 and HTTP/3 are more focused on guaranteeing delivery of ads than being able to block malicious activity.
I don't follow your reasoning. So you have the ability to block QUIC, but declare QUIC to be a "bad actor" trying to bypass your network management?
They switched from TCP to QUIC base, what can be done over HTTP3 can also be done over HTTP2.
From the POV of the network it is much more similar to a UDP VPN than to HTTPS over TCP
I fully support user choice to disable whatever protocol they want. I also think modern browsers lack options in this department. If you dislike QUIC, which I can completely understand, you should disable it.
On the server side, though, you can use modern servers and tell all your clients to stick with HTTP 1.1. Let the people who do like QUIC (or don't care) get the benefit of faster page loads and lower latency. HTTP/2 and HTTP/3 solve some real performance issues, particularly for users with unstable or slow internet connections. I don't see why would would deprive them of that simply because you prefer to have the protocol disabled.
But networks often block them for security reasons, and it's their network and prerogative to do it as a condition to use the network.
> Block whatever stupid protocols Windows uses for file sharing so you don't leak your credentials, that's all the outgoing filtering you need.
It's clear that you've never managed networks that need to meet stringent security requirements.
> Universities are research facilities, they're supposed to be at the forefront of technology, not run into service issues because their policies are frozen in the late 90s.
It's also clear that you've never worked on infrastructure in a large heterogenous environment that grew organically over decades. Or dealt with infrastructure that was grant funded.
Yeah both of those problems are solved or alleviated with tooling but it can take years to get all the disparate systems managed in house.
This isn't the first post the author has made about their university's network infrastructure. The HTTP/3 issues start being named years back.
The university, as an organisation, doesn't seem to want to move away from the old way of doing networking. There's no indication this is a "we have to hotfix it for now because our new systems are done in 2030" network, and every indication that they're stretching their current design for as long as it'll hold.
Even if they're doing this for security reasons, the days of unsecured bastions with a strict firewall around them, as suggested by their latest infrastructure blog post, are long gone. I highly doubt security is the reason the university can't move on.
With no migration plans as far as I can see, they're setting themselves up for failure again when HTTP/4 inevitably comes around, or when strict networking peculiarities cause the next QUIC/HTTP3/TLS 1.3 bug the author will have to dive into and figure out.
That need to meet overreaching legal compliance requirements, maybe, but this isn't the same as security.
> you've never worked on infrastructure in a large heterogenous environment that grew organically over decades. Or dealt with infrastructure that was grant funded.
I should hope you don't need to be an outsider/inexperienced to point out obvious dysfunction. Yes, said dysfunction almost always has very explainable context and causes (organic growth over decades, inconsistent/dependent funding structures, etc.) but neither negate the fact that it is a form of dysfunction, nor should they put it beyond criticism (from inside or out).
Just because some guys out west had an idea and therefore it's the "new thing" doesn't mean that it the right thing for everyone.
Organizations who are not doing this are not adequately managing their network.