“Strict” HTTPS-only mode

Sometimes sensitive information is, for various reasons, inadvertently sent over plain HTTP connections; by the time an HTTP request reaches Cloudflare, everything in it has already been exposed.

It would be great if I could set some of my :orange: domains to be “strictly” HTTPS-only. Cloudflare would resolve them to addresses that don’t accept 80/TCP connections.

What do you think?

Generally not a bad idea, though it will require domains with that setting to be moved to a separate IP range, as the proxies cannot not listen port 80 only for certain domains.

Right now you could somewhat achieve that already by enabling HSTS. Not exactly the same thing but close enough.

However, considering Cloudflare offers an encryption breaker like Flexible I am not sure I’d be all that worried about this ;). My vote nonetheless.

1 Like

Even with HSTS preload, I still get some unencrypted traffic (in KB):

So this would be a plus.

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.

Go one step further and enable HSTS preload.

There are also some directives in CSP that can help eliminate HTTP, including block-all-mixed-content and upgrade-insecure-requests.

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 1.0.0.0/8 network, with ~150Mbps of continuous traffic being received on a network that had previously not existed in the DFZ.

2 Likes

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.

See

In March, when Cloudflare announced 1.0.0.0/24 and 1.1.1.0/24, ~10Gbps of unsolicited background traffic appeared on our interfaces.

More on that in the post.

1 Like

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.

Maybe move the HTTPS redirect temporarily from Cloudflare to your server. In this case the HTTP requests should show up in your log and that might tell you more.

Yeah, but @chasers’s Logflare for example shows only 45 in the last 30 days, all from Atlanta’s DC, for some reason… I don’t know what the others are since his Worker runs everywhere CF is enabled.

1 Like

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 :slight_smile:

I am more surprised they don’t at least now try to connect at least to HTTPS first or both and then select the best option available…

Well, technically you can have two completely different things running on HTTP and HTTPS, so I understand why they might want a single default protocol and not switch dynamically.

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.