> It is not an attack when it has been explicitly chosen by the web site to
> host their web server.

I don't care if it is the choice of the website to let Cloudflare host their 
content. It is their choice, so I can't counter it. However, the point I am 
making here is to explicitly let Chromium's users know that another party can 
read the secure connection they are making to the website (from now on I will 
call it websites instead of servers, see next). It is also still an attack, 
because the client doesn't know that another party can read the secure 
connection.

> And so it does here. Here end to end is between the client and the server.
> The server is a CloudFlare server. They are being commissioned to host the
> web site. They are therefore terminating the TLS connection endpoint. Since
> they are the web site server.

I chose the wrong word, which is "server", so let me clarify that. When I said 
"end-to-end between the client and the server", I meant "end-to-end between the 
client and the website". If we look at a Cloudflared TLS encrypted website, we 
can't say it is end-to-end encrypted between the client and the owner of the 
website (which is not Cloudflare), because another party commissioned by the 
website owner intermediate the connection between the client and the website 
owner, which means that party can virtually see all connections, TLS or not, in 
cleartext (unless there is another encryption, like PGP). I agree with you that 
it is end-to-end encrypted between the client and the server (which is owned by 
Cloudflare), but if you're saying it is end-to-end encrypted between the client 
and website, you're wrong. What I would like to say here is to give the user or 
client an option whether to trust that third-party (Cloudflare) or not. This is 
a very serious issue, Chromium didn't notify the user that another party can 
read their connections, and the user thought that only them and the website can 
read the connections. This why I made the bug's priority grave, not wishlist. 
So I am asking you, please, to reopen this bug and re-raise the priority to 
grave.

> When CloudFlare is commissioned to host a web site then they host that web
> site. They are not "unintended". It is no different from any other web site.

They are unintended because the user is not made aware that another party can 
read their sensitive data like passwords.

> If you do not trust the server site then you also cannot trust headers that
> it is sending. And just from a practical perspective those headers might not
> exist at all or might be different for every hosting provider or might be
> changing very frequently. All of those things make using such headers
> problematic.

Then we can use Cloudflare's SSL certificate which is use to "secure" 
Cloudflared sites. I don't know though if other similar Cloudflares use their 
own certificate to encrypt the sites they host.

Reply via email to