> this is still better than "no SSL whatsoever"

This breaks the expectation that if a website is using HTTPS the connection is encrypted from source to destination. I'm not sure it's better as it's effectively giving the user a false sense of security.

I'm not sure this is the reputation of HTTPS: people have no idea what HTTPS means besides "the website is secure". It's your job, as a server admin, to choose how you deal with your infrastructure. If you choose to not use TLS between you and cloudflare, then you made a decision (that is fundamentally better than no TLS at all). If something happen, because Cloudflare, or because MITM between CF and you, then it is not on the user but on you.

FWIW a lot of infrastructure terminate TLS at the load balancer as well. HTTPS does not mean e2e encryption. HTTPS means you're securely talking to their infrastructure.

You may think it's fundamentally better then no TLS, and it may be on some levels, but where it's displayed to the user, it's seen as "This is HTTPS", with no mention of "it switches to HTTP for the last half of the trip". I don't want my credit card details and login info routing over the public internet in plaintext, but thanks to CF, I can't tell if they are or aren't. Oh sure, I won't get mitm'd by a coffee shop, but that "gain" is less then the loss of "oh, it's got the lock, that means it's secure"

But an infrastructure can make bad decisions at any point. They could terminate the tls connection at a wrong node, they could store your data unencrypted, they could... All of this is not on the user. It's on the company. And if they do decide to use Cloudflare this way it is their architecture decision.

Yes, that is all understood. The fact remains, however, that they are basically subverting what that lock means. It's ALL ON THE COMPANY, but I can't tell as a user that they have broken it, and in fact, my browser is SAYING it's secure. The company is deciding to make it lie. THAT IS A PROBLEM.