Project

General

Profile

Bug #11629

Padlock icon appears on MitMd Firefox connections

Added by cypherpunks about 3 years ago. Updated over 2 years ago.

Status:
Rejected
Priority:
Elevated
Assignee:
-
Category:
-
Target version:
-
Start date:
08/10/2016
Due date:
% Done:

0%

Feature Branch:
Type of work:
Communicate
Blueprint:
Starter:
Affected tool:

Description

Whenever a CloudFlare site is accessed, Firefox shows the user a padlock. This is a false signal, misleading users to believe they have established an end-to-end tunnel. All CloudFlare sites are inherently MitMd by design:

http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/

A majority of the public unwittingly shares sensitive information with a single corporation that's unknown to most users. This is a severe security problem, and it is rampant. Money is literally on the line. To illustrate the gravity of the problem, consider these bitcoin services that expose all Tails users web traffic to CloudFlare without their knowledge or consent:

  • bitcoin.de
  • bitcoin.it
  • bitcoinist.net
  • bitpay.com
  • biteasy.com
  • localbitcoins.com
  • seebitcoin.com
  • gocoin.com
  • 1broker.com
  • simplefx
  • fxopen
  • uphold
  • First Global Credit

etc.

This bug report should be treated with very high priority. In addition to money loss, all usernames and passwords are being exposed to CloudFlare without users knowledge or consent.

Solution:

The browser should examine the http headers and replace the padlock with a caution triangle if "cf-ray" matches any of the headers.

History

#1 Updated by alant about 3 years ago

  • Type of work changed from Code to Communicate

This is indeed a problem, but the solution will not happen in Tails but rather in Tor Browser or even in Firefox. Would you please report the issue there?

#2 Updated by cypherpunks about 3 years ago

alant wrote:

This is indeed a problem, but the solution will not happen in Tails but rather in Tor Browser or even in Firefox. Would you please report the issue there?

This has been a quite difficult bug to report.

Mozilla bug tracker problems

First I tried reporting directly to Mozilla, but Mozilla does not accept anonymous bug reports, and their registration system is wouldn't accept my e-mail address.

Torproject bug tracker problems

Trac.torproject.org accepts anonymous reports, but their captcha is broken. I could not get past the captcha.

Debian

I was able to report the bug to the Debian IceWeasel project, but it's ignored there (not really surprising).

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831835

#3 Updated by emmapeel about 3 years ago

  • Status changed from New to Rejected

We cannot decide which services website admins decide to use. It is a sad situation, I feel you, but it is a decision of the website administrators.

It is not even a Firefox or Tor Browser problem. Maybe you want to talk with the specific site admins?

#4 Updated by intrigeri about 3 years ago

I agree with emmapeel: this is very painful, but outside of the scope of Tails' mission.

#5 Updated by cypherpunks about 3 years ago

We cannot decide which services website admins decide to use.

You're not being asked to.

It is a sad situation, I feel you, but it is a decision of the website administrators.

Browsers serve the user, not the web admins.

It is not even a Firefox or Tor Browser problem.

Of course it is. The browser renders the padlock.

Maybe you want to talk with the specific site admins?

Don't make this about me. This is about the average layperson being shown a padlock from a Tails app, clearly misleading them to think their secure. These are the users you're endangering.

#6 Updated by cypherpunks about 3 years ago

I agree with emmapeel: this is very painful, but outside of the scope of Tails' mission.

When you mislead users with false security indicators, you are in fact undermining Tails' mission.

#7 Updated by intrigeri about 3 years ago

When you mislead users with false security indicators, [...]

There is no such thing as binaries "false" or "true" in this area: at one level or another, the huge majority of the web sites' hosting, and the power over the bits that are served to the user, is at least partly delegated to a third-party (website hosting, server hosting, VM hosting, managed to some level, with some bits in the cloud, etc.). CouldFlare is just one example of such a third-party.

What we can convey to the user is whether they are connected to the remote peer that the web site administrator decided to delegate their web site's hosting to. This is what Firefox, Tor Browser and all other major browsers do. It's the best we can do given the current state of research and code.

Still: I, for one, would find it very interesting to see usable security research about how to convey more fine-grained information about how much a given piece of web content is tainted by 3rd-parties. I'm not too hopeful, though, wrt. the quality of the information that can be guessed and conveyed to the user, in practice, by a web browser. In any case, doing such research is definitely not part of Tails' mission, and keeping a ticket open in this bug tracker is unlikely to produce the outcomes you or I may wish for, so insisting about it here won't help at all. Looking for usable security researchers who are interested in this topic has greater chances to produce more useful results, and less frustration.

#8 Updated by cypherpunks about 3 years ago

@intrigeri

It's the best we can do given the current state of research and code.

By research, do you mean joepie91's article is possibly flawed? Or are you talking about psychological research into how the typical user perceives the security icon?

Still: I, for one, would find it very interesting to see usable security research about how to convey more fine-grained information about how much a given piece of web content is tainted by 3rd-parties.

Of course our heads are probably teeming with ideas on how to get more detailed security info to the user. I have all kinds of creative and radical ideas about that. But here we're talking about the padlock alone. The padlock is a blunt instrument. It's a boolean, true or false (showing or not). Given that it's blunt, it's a bad idea to give the benefit of any discrepancies to the website instead of the user whom the browser serves. The safe approach is to inhibit the padlock whenever there is any indication that the tunnel is unsafe or not terminating with the sole entity the user believes they are transacting with.

In any case, doing such research is definitely not part of Tails' mission,

Tails does not simply bung in any apps users like. Only apps deemed secure are approved on the Tails distro. Hence why it's an awkward size (more than 700mb, but far less than 4gb). TBB has the nasty pitfall of over-reassuring the user about security. TBB is unfit for Tails. Obviously a secure browser is very central to Tails use-cases, so Tails should do the necessary to get a secure browser. Which means fixing the bug.

keeping a ticket open in this bug tracker is unlikely to produce the outcomes you or I may wish for

Indeed this may need to be escalated upstream to Tor project. I tried, but their bug tracker has issues. Also note that the Tor Project is in a terrible state right now.

#9 Updated by cypherpunks about 3 years ago

cypherpunks wrote:

Tails does not simply bung in any apps users like. Only apps deemed secure are approved on the Tails distro. Hence why it's an awkward size (more than 700mb, but far less than 4gb). TBB has the nasty pitfall of over-reassuring the user about security. TBB is unfit for Tails. Obviously a secure browser is very central to Tails use-cases, so Tails should do the necessary to get a secure browser. Which means fixing the bug.

This would be more of an improvement than a huge bug. If it were bad enough to be a blocker, it would make Tor Browser (it's not TBB anymore, especially on Tails) considered not acceptable for usage in Tails. But it's not.

Indeed this may need to be escalated upstream to Tor project. I tried, but their bug tracker has issues. Also note that the Tor Project is in a terrible state right now.

Those issues are non-fatal. I'm sure you'll be able to find a way to get past them. Alternatively, you can discuss the issue with the maintainers directly, or through IRC (or XMPP?). As for the issues with Tor Project, sure, there's some drama going on. But that's not going to make it harder to report bugs.

This is really more of a research issue anyway. Not only is there the issue of Cloudflare, but how can you tell if a service is "MITMed" in another way, such as using its own CDN, or a 3rd party CDN, or just a frontend with the private key, and behind a GRE tunnel is the real server? There's no way to tell. I'd say that focusing on pointing out Cloudflare would present a false sense of security, even if it were practical to do.

#10 Updated by cypherpunks over 2 years ago

If this bug report had been properly treated, Tails users would have been protected from CloudBleed.

#11 Updated by cypherpunks over 2 years ago

cypherpunks wrote:

If this bug report had been properly treated, Tails users would have been protected from CloudBleed.

The green lock is for notifying users that the connection between the client and the server is confidential and authenticated. It says nothing about what the server does with the data once it has it. If the server is broken and sprays the data everywhere, à la Cloudflare, it is not the job of the browser to notify the user, no more than it is the job of the browser to notify the user if the connection is with a server that has a poor privacy policy, or with a server that extensively logs, or with a server owned directly by the Department of Defense itself. The only thing it should ever do is tell whether or not, from a SIGSEC perspective, the connection is maintaining an adequate level of confidentiality and authentication.

In technical terms, you are asking Tor Browser to attempt to solve all COMSEC issues regarding TLS, a fundamentally impossible task. All that is in the scope of the lock icon is to attempt to notify the user of issues regarding SIGSEC, nothing else. It's as simple as that. Trying to solve any other issue with it is futile.

The lock icon is meant to tell the user when there are problems with SIGSEC, not COMSEC.

As mentioned before, if you really want this bug considered, report it upstream, either to Tor Project, or to Mozilla, but I imagine you'll get the same response.

Also available in: Atom PDF