You are looking for a TCP firewall rule to block everything except port 443, so even a version of the managed special rule 100015 would not help. (That rule has a HTTP firewall block on all ports except 80 and 443).
I believe Workers will support pure TCP applications in the future, which might give you the control you are looking for. I have no idea if such applications will still have access to the full HTTP feature set.
Agree, but its unlikely to happen for a very long time. Browsers default to 80, and I have not seen any proposal to change this, even following RFC7258. If users typing an address in the browser is still a substantial source of traffic, the majority of sites will need 80 on www and the naked domain. But for non-user interactive hostnames 443 only would be preferred.
I’m curious as to how much sensitive information can be exposed over HTTP if you have used all the mechanisms available to demand user-agents use HTTPS?
This could be just random scanners. I recall that Geoff Huston/APNIC did some analysis 10 years ago on traffic to the previously unused 126.96.36.199/8 network, with ~150Mbps of continuous traffic being received on a network that had previously not existed in the DFZ.
I guess if someone, or some piece of software, runs curl http://example.com/?MySocialSecurityNumber=123-45-6789 it’s not great for Cloudflare (and all the hops in-between!) to see that traffic at all. If CF had some IPs set to block port 80, the TCP connection wouldn’t initialize so no HTTP information would be sent across the wire.
In March, when Cloudflare announced 188.8.131.52/24 and 184.108.40.206/24, ~10Gbps of unsolicited background traffic appeared on our interfaces.
Well on my domain, which is on the preload list of HSTS since early at least 2017, serves everything on HTTPS, redirects to it everywhere, doesn’t have many actual external visitors still got >750 unencrypted requests to Cloudflare in the last month out of ~4M. I can’t really get to where or from who though.
True, and I am a bit surprised Google hasnt pushed for it to default to 443 yet. But I assume they consider the 20% HTTP URLs (have we really come that far already, not bad) still too high to risk a possible “connection refused” message or hope for HTTPS setups which redirect to HTTP. Nonetheless I guess this will change within the next ~5 years.
I’d argue, though, that it wouldnt be applicable to the use case the OP mentioned, as those would be setups where the maintainers actively opted in not to have port 80 online. Obviously that setting should not be enabled by default, as long as browser default to port 80, but as an optional feature it might be worth to be considered on the journey to encryption
Browsers aren’t the only applications using HTTP(S) and I guess it’s safe to say that most of them don’t support HSTS.
Here’s an example: I’ve observed Microsoft Office applications (other than Outlook) regularly making Autodiscover requests over plain HTTP. These requests don’t contain user credentials, but they do expose user identifiers (email addresses) to everyone listening in on the wire.