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

[Bob Proulx]

severity 885989 wishlist
tags 885989 + wontfix
thanks

TemTem wrote:
> A large portion of websites are being (willingly) attacked by
> man-in-the-middles (MitM) such as Cloudflare.

When someone commissions a service provider such as CloudFlare to host
their web site CloudFlare then of course CloudFlare hosts their web
site.  Since CloudFlare is hosting then of course they are also
terminating the TLS endpoint connection.  That is inherently how
things work.

The decision is made by the web site owner.  It is their choice.  They
can choose host at CloudFlare or at another hosting provider or they
can build up their own infrastructure.  It is their decision.

> Chromium aims to provide a SAFER web browsing experience, but it
> fails to do that by not preventing users from being attacked by a
> MitM.

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

> TLS is designed to protect against MitM attacks by providing
> an end-to-end encrypted connection between the client and the
> server.

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.

> Cloudflare and other similar services undermines TLS by decrypting
> the connection, which is a very grave security and privacy concern,
> especially for Tor users. If passwords are entered in a such service
> pwned site, whether you are using TLS or not, the password (and any
> other sensitive data) would be known by an unintended third-party.

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.

> How can Chromium know that the user is visiting a MitM-ed site?
> Let's look at Cloudflare. Cloudflare uses a "cf-ray:" HTTP
> header. Similar services probably has a similar kind to the
> "cf-ray:" header too. Use those headers and whatever kind which will
> identify that the site is pwned.

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.

Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-chromium-maint/attachments/20180106/ff2f851c/attachment.sig>