Wandering Thoughts archives

HTTP/3 needs us (and other people) to make firewall changes

The other day, I had a little realization:

Today I realized that the growing enabling of HTTP/3 means that we need to allow UDP 443 through our firewalls (at least outbound), not just TCP 443. Although in the mean time, blocking it shields our users from any HTTP/3 issues. (Which happen.)

Like many places, our network layout has firewalls in it, in fact quite a lot of them. We have a perimeter firewall, of course, then we have firewalls between our internal subnets, our wireless network has a firewall, and our VPN servers have their own set of firewall rules. All of our firewalls have restrictions on outbound traffic, not just inbound traffic.

For obvious reasons, all of our firewalls allow outbound traffic to TCP port 443 (and port 80, and a number of others). However, some of them don't allow outbound traffic to UDP port 443, because there's been no protocol that used that. Until now. HTTP/3 uses QUIC, which runs over UDP, and so it thus generates traffic to UDP port 443. Right now any such traffic is probably not getting through.

Google's Chrome has enabled HTTP/3 (and QUIC) for some time, Firefox enabled HTTP/3 by default in Firefox 88, and Microsoft Edge has also had it for a while (Apple's Safari has yet to enable it by default). All of those browsers will now be sending traffic to UDP port 443 under the right circumstances, or at least trying to; while our firewalls block that traffic, they're not getting very far. I don't know how HTTP/3 implementations behave here, but I wouldn't be surprised if this creates at least a little bit of a slowdown.

(Of course this may shield people from a great deal of slowdown if HTTP/3 appears to work more.)

We're not the only places who are going to need to update firewalls to enable outbound UDP port 443, of course. But I suspect that Google (the originators of the whole QUIC idea) has studied this and determined that there are fewer firewall blocks in the way than I might expect.

Eventually we may also want to enable inbound UDP to port 443, so that people can run web servers that support HTTP/3. But that will probably take much longer, because server support is apparently rather lacking right now (based on the Wikipedia list). So far most of the web servers we run don't even have HTTP/2 enabled yet, for various reasons.

New versions of Bash (and readline) default to special handling of pasting into the shell (or other programs)

Our standard habit on our OpenBSD machines is to use their packaged version of Bash as the root shell, instead of the default of OpenBSD's version of ksh. When I set up an OpenBSD 6.9 machine recently and started to paste in install steps from our standard instructions, an odd thing happened: the line I'd just pasted in was highlighted in reverse video and Bash just sat there, instead of doing anything. After some fiddling around, I discovered that I had to hit Return in order get things to go (and at that point Bash would act on all of the input without further prompts, even if I'd pasted in multiple lines).

People who are more familiar with Bash and readline than I was already know what this is; this is the Bash readline setting of enable-bracketed-paste. OpenBSD 6.9 is the first Unix I've encountered where this was turned on by default. This isn't because OpenBSD did anything special; instead, it's because OpenBSD 6.9 is the first Unix I've used that has Bash 5.1. As mentioned in the detailed Bash list of changes, bracketed paste mode was enabled by default starting in bash-5.1-alpha. The reverse video behavior of it is also new there; in 5.0 and before, nothing special shows in bracketed paste mode to signal that something unusual is going on.

Bash 5.1 will be rolling out over time to more Unixes, so I suspect that more people will be running into this behavior unless their particular Unix opts to disable it in one way or another. If I had updated to Fedora 34 by now, it's possible I'd have already encountered this (I believe that Fedora 34 has Bash 5.1, but I don't know how Fedora opted to set bracketed paste).

This change to the default of bracketed paste is also in GNU Readline 8.1 (according to its CHANGES). However, Readline has a configuration time option that can change this, so different Unixes may opt to build Readline differently. On a Unix with Readline 8.1+ and bracketed paste enabled by default, I believe that all programs using GNU Readline will automatically have this behavior.

(This directly affects me because these days I build my alternate shell using GNU Readline. If I do nothing, it will someday inherit this behavior on new versions of Fedora and Ubuntu.)

If you decide that you don't want bracketed paste mode, the safest change is to set this in either your $HOME/.inputrc or globally in /etc/inputrc. You would do this with:

set enable-bracketed-paste off

This will (or should) cover Bash and anything else that starts using Readline 8.1 on a Unix that builds 8.1 with this enabled. Adding this to your .inputrc today is harmless if you have Readline 7.0 and Bash 4.4 or later (the versions where this setting was introduced).

If you just want to turn this off only in Bash (at least for now), I think that you want to set up a $HOME/.bashrc that has in it:

bind 'set enable-bracketed-paste off'

You can set this in your .profile, but then it won't be turned on in subshells.

How to set this bind up globally for Bash depends on how your Unix's version of Bash was built and may not be possible. Ubuntu builds Bash so that there's a global /etc/bash.bashrc you can put this bind into, but Fedora and OpenBSD don't. Fedora provides a starting .bashrc for new accounts that source /etc/bashrc, so you can put the bind there and probably get most people. Since Bash is an add-on in OpenBSD, it has nothing like this and people are on their own to disable it one by one.