Hacker News Reader

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.

Is this the earlier post you were thinking of? https://utcc.utoronto.ca/~cks/space/blog/sysadmin/HTTP3AndOu...

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?

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.

Man, what a condescending tone you take.

> 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).

> 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 wouldn't call those network protocols as "terrible 80s designs" rather quite opposite, great design that lasted decades.

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.

Yes but those tweaks are largely designed to be backwards compatible. Unreachable server our problem/unreachable Gmail their problem is real.

Wow, I took away completely different things from this article than you.

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.

> Network management is there for a purpose, and the people focusing on bypassing it are generally bad actors

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.

QUIC is completely opaque to the network, TCP exposes a lot of information about the connection(s).

From the POV of the network it is much more similar to a UDP VPN than to HTTPS over TCP

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.

That's a reasonable position. And don't get me wrong, I understand there are situations and reasons as a client to want these tools available.

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.

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.