[Pkg-chromium-maint] Bug#885989: chromium: MitM-ed TLS sites are being recognized as secure even though they are not

[TemTem]

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-chromium-maint/attachments/20180111/2fa51f59/attachment.html>