[kelnos]

As a website visitor this has always bothered me. HTTPS used to mean that I had an encrypted path between my browser and the server actually serving the webpage. With Cloudflare allowing this weird hybrid mode, I can never actually know if the connection is secured all the way end to end.

[jacobparker]

cloudflare didn’t invent this or make it normal. It’s always been common to terminate https in front of your “actual” server and with re-encrypt to the “actual” server or (very common) ... don’t.

Cloudflare may have made it more common for the most basic kind of site (with their easy setup and free tier) but at the same time most of those sites probably didn’t use https anyway.

The reasons this has been done are performance (specialized hardware/separation of concerns) load balancers/firewalls needing to decrypt to route/enforce policy (that doesn’t need to imply termination but it often goes hand-in-hand) and protecting keys from your app server (think of it as like an HSM - if your app server gets compromised you probably don’t want the TLS private key to be leaked. Again you could reencrypt with a different key but often this hadn’t been done.)

The threats for last mile network fuckery (e.g. consumer ISP) are quite different then on the backend. Google has to worry about nation states messing with their networks and so they’ve had to reengineer end-to-end encryption within their network. As an end-user you just sort of need to accept that this isn’t within your ability to control or know.

[JetSpiegel]

Reverse proxy were usally not routed through the Internet, only a local network.

[jacobparker]

Sure but the GP made a much stronger claim that they previous knew that it was the “actual” server terminating HTTPS.

Even still, the difference between this and e2e encryption isn’t something an end user is really equipped to evaluate IMO. The threat model is practically different vs e2e no-encryption.

Cloudflare also supports reencryption over the net which is useful if your hosting provider supports HTTPS but not via a custom domain (e.g. Google clouds GCS (S3))

[kelnos]

No, I didn't make that stronger claim; if that's what it sounded like, I apologize for the poor wording. I was definitely assuming "terminate TLS at load balancer and proxy in the clear over internal, private network" as a common, long-established practice that I have no problem with.

With services like Cloudflare, you can terminate TLS at CF, and then proxy over the public internet to the server that actually serves the page, which I think defeats a lot of the purpose of TLS, and I can never know ahead of time when I request a page of HTTPS if this will in fact be what's happening.