Tails

#2 Updated by cypherpunks 2016-08-13 23:13:28

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

#4 Updated by intrigeri 2016-08-19 11:44:43

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

#5 Updated by cypherpunks 2016-08-26 11:40:07

> 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 2016-08-26 11:46:07

> 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 2016-08-26 12:27:19

> 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 2016-08-29 11:19:35

@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 2016-08-31 04:32:08

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 2017-02-24 21:32:03

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

#11 Updated by cypherpunks 2017-03-04 01:39:12

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.