Icon base by Lorc under CC BY 3.0 with modifications to add a gradient
Yes. Reverse proxies need to own the private key which belongs to the FQDNs certificate for the TLS connection between rproxy and browser. Also, sometimes HTTP Headers need to be rewritten.
As a result there is no end to end encryption between the server and the browser. You need to trust cloudflare as you need to trust your hoster.
TLS isn't really related to E2EE. E2EE data can be delivered securely over http without any transport encryption, as long as the secrets/passwords/keys themselves never leave the client unencrypted (the data is encrypted by the client before transport).
A cloudflare hosted/protected site can still provide E2EE. You just have to trust that they aren't going to conduct any sophisticated transport attacks to inject malicious code and surreptitiously obtain your secrets.
TLS isn't really related to E2EE.
IMO it is. Is it not a solution which prevents everybody but the client's browser and the web-server from taking part in the communication? Why?
data can be delivered securely over http
On top of HTTP? Nice. Is there a RFC or a framework which implements such a solution?
Yes indeed.
Ever try visiting an overloaded HTTPS site and get an HTTP 524 error page? Cloudflare's ability to insert those pages in place of the expected response makes it clear that your "secure" connection only reaches as far as Cloudflare, who can read and modify everything you send to and receive from the site you're visiting.
Given how much of the web runs behind Cloudflare, along with their position as the early default DNS-over-HTTPS provider in browsers, they are a massive man-in-the-middle constantly watching and capable of modifying much of our web activity.
