Tails

#2 Updated by sajolida 2014-04-07 21:22:34

> 1)By opening the same homepage everytime you start tails, or choose
> “new identity,” increases the probability of a drive-by/mitm attack
> on tails.boum.org or whatever site is the home page. Whatever page
> is choosen will become a more serious target for compromise, either
> directly or mitm.

I don’t understand your point here. What kind of mitm attack are you
talking about? And how would they affect the user?

> 2)It seems this would also be a vector for a timing attack on the
> local connection, for what it is worth, since you know every browser
> circuit will go to that page.

Tails already connects automatically on our RSS feed for security when
starting. Do you think that having two connections instead of one
increases this risk?

> 3)Some users may want to change their noscript or other settings
> before connecting to any page.

The current homepage has no Javascript.

Plus, we chose to display our news page because we feel it is important
for the users as well as for the project to keep them informed this way.

#3 Updated by grnstar 2014-04-08 02:29:47

_I don’t understand your point here. What kind of mitm attack are you
talking about? And how would they affect the user?_

I think molibdeedee has a valid point here. He is referring to the homepage tails.boum.org. In case that gets compromised an adversary can theoretically put malicious code on that page and since all Tails users have java script enabled by default all an adversary would need is some malicious to compromise thousands of Tails in a really short period of time before it is discovered.

_Tails already connects automatically on our RSS feed for security when
starting. Do you think that having two connections instead of one
increases this risk?_

Again going back to my earlier point, I think having all Tails users visit one page on startup of their browser is a huge op-sec error. Whether it’s from comprimising tails.boum.org or just simple traffic analysis, an attacker can get a better idea. In other words if an adversary does traffic analysis they can deduce that the user has just started their Tails and connected, which gives them more intel.

_The current homepage has no Javascript.

Plus, we chose to display our news page because we feel it is important
for the users as well as for the project to keep them informed this way._

You are correct in that in has no javascript, but if it is compromised an attacker can inject malicious code into thousands of Tails users browsers.

Your news page is informative but personally I don’t think it’s worth it at the cost of a users security.

Ideally the Tails news page can be a bookmark in the default Tails browser and the homepage can be a simple about:blank page or point to a local file (ex. default.html) which has a simple message of tails connected and have a few obvious links point to Tor check page and Tails news.

Other than the obvious privacy and security benefits the icing on top would be a faster load time due to the browser loading a local html file as opposed to a remote one.

#5 Updated by darkgrid 2014-04-08 20:40:47

For the time being until this issue is fixed here is how I go about it:

1. before connecting to a network open the firefox browser and right-click and turn on no-script

2. connect to the network

This way when tor connects and auto launched my browser it already has no-script on instead of off by default.

In reality the chances of the Tails homepage being compromised is very low however we shouldn’t ignore it just because the change is low.

Things have happened in the past where the chances were really low and people never thought it would be possible but it happened (ex. FBI inserting malicious java script which phones back home to an undisclosed server).

The easiest solution would be to put a simple local html file with some basic info and links to Tails news and the Tails homepage.

#6 Updated by sajolida 2014-04-08 22:13:00

> I think molibdeedee has a valid point here. He is referring to the
> homepage tails.boum.org. In case that gets compromised an adversary
> can theoretically put malicious code on that page and since all Tails
> users have java script enabled by default all an adversary would need
> is some malicious to compromise thousands of Tails in a really short
> period of time before it is discovered.

Ok, I understand now. Your concerned is not necessarily about a MitM but
rather about the original page getting compromised in general.

> _Tails already connects automatically on our RSS feed for security
> when starting. Do you think that having two connections instead of
> one increases this risk?_
>
> Again going back to my earlier point, I think having all Tails users
> visit one page on startup of their browser is a huge op-sec error.
> Whether it’s from comprimising tails.boum.org or just simple traffic
> analysis, an attacker can get a better idea. In other words if an
> adversary does traffic analysis they can deduce that the user has
> just started their Tails and connected, which gives them more intel.

A “better idea” of what exactly?

Such an adversary should be able to look at both the local ISP and the
destination server in order to what? Identify someone as a Tails user?
Identify the user of a Tor circuit that could be reused shortly after?

First of all, we do not pretend it is possible to strongly hide the fact
that you are using Tails in the current state of things.

See https://tails.boum.org/doc/about/fingerprint/

Second, Tor cannot really preserve your anonymity from a global
adversary that can observe both your local ISP and the destination
server. Whether you are visiting tails.boum.org, google.com, or anything
else.

See https://tails.boum.org/doc/about/warning/#index7h1

So for me, the only possible attack that would be prevented by a local
file would be in case our homepage gets compromised.

By the way, could you find in the Tor bug tracker any archive on why
they decided to use a local file?

> Ideally the Tails news page can be a bookmark in the default Tails
> browser and the homepage can be a simple about:blank page or point to
> a local file (ex. default.html) which has a simple message of tails
> connected and have a few obvious links point to Tor check page and
> Tails news.

If we decide to not connect to the news page, then the solution you
decide seems good to me.

#8 Updated by molibdeedee2 2014-04-12 19:39:56

> Ideally the Tails news page can be a bookmark in the default Tails browser and the homepage can be a simple about:blank page or point to a local file (ex. default.html) which has a simple message of tails connected and have a few obvious links point to Tor check page and Tails news.

A local file would better match traffic behavior of Tor Browser. If that can be done for free, why not?

> using a local homepage (with links to key pages) would make it less
> likely that users read our news, and people who see the “not enough
> memory to check for upgrades” thing won’t know that there’s a new
> Tails available.
This is a valid point. However, one that a user might only want to see when they first start tails, not every time they use the “new identity” feature.

I think the solution is to:
1) Insure connections RSS or whatever to check for updates are done in
a) seperate circuit,
b) once, and
c) when tails network connection is established and working.
d) Ideally with wget or curl, which is probably more secure than browser and doesn’t execute javascript code.
2) Use a local file similar to torbrowser.

> Such an adversary should be able to look at both the local ISP and the
> destination server in order to what? Identify someone as a Tails user?
> Identify the user of a Tor circuit that could be reused shortly after?

The difference is, the adversary in this case doesn’t have to know something special about you to know your dest server. They know you will connect to tails.boum.org:443. And they know that will happen on every browser circuit. They don’t have to be a “global adversary.” They could be watching tails.boum.org, or they could be a malicious admin. So by watching someone’s local connection, and by watching tails.boum.org, they can determine fairly easily, your exit node for each circuit. They can then match up these ip’s with other ips in other logs they may have access to, to determine, for instance, that you connected to a particular web-based email/hidden service/whatever. By removing the constant hitting of tails.boum.org, we get back to having to be a global adversary, or having specific knowledge of user. Removing the homepage limits “intelligence.”

Having the homepage also makes tails.boum.org more highly desired to be compromised. As far as ISO’s, people should be, and are, highly cautioned to verify images via PGP. As far as rouge CA, we know this is a legitimate attack. Compromise could be instantaneous for thousands of users, and seems low-hanging fruit compared to other compromise methods.

It is also hard to say what a particular user might be interested in doing. A highly cautious user may not use the browser at all. But someone in between, may wish to have JS disable ASAP, or other needs for setting up browser we may not be aware of. Perhaps such a user knows a zero-day that can be fixed via about:config page, and wants to fix that before connecting http/https to anything. Its hard to say. I think a solution to this needs to have the user notified of updates, but not introduce new threats.

#9 Updated by molibdeedee2 2014-04-12 19:48:45

The key thing here that puts this in a seperate category then other threats, is the garunteed and repeated connecting to the same resource. This is not the case with any other page a user may access. A global adversary is not necessary, just someone who can watch local and/or tails website.

When me must connect to a particular resource for every instance of running tails, then that connection should be as secure as possible.

As far as I know, we clearly connect to the dir servers and then entry guards. We connect to the servers for setting the date. And then the update server RSS. On the Tor side, nothing we can or should do about that. All other mandatory connections we must do the best we can to insure the best security possible since they are the lowest hanging fruit for an attacker.

> The current homepage has no Javascript.

Well that could be changed by the attacker.

#10 Updated by molibdeedee2 2014-04-12 20:17:27

The core points with this (bug):

1. The connection happens on every browser circuit.
2. By design, browser circuits do not use IsolateDestAddr/Port flags. The “New Identity” feature of TorButton clears the browsers history and requests a new tor circuit for subsequent connections.
3. An adversary only needs local timing information, and ability to watch tails.boum.org, in order to determine exit nodes for browser circuits. The adversary does not have to be a “global passive adversary.” If adversary was a “global passive adversary,” then the connection to tails.boum.org, could only make things easier for them.
4. Having times and exit nodes, adversary can then, at a later time, find other logs and determine with decent surety, that the user connected to those other pages.
5. Adversaries have shown the ability to mitm https sites through rouge CA. Generally what we seen has been JS, but it is agreed this may not be necessary. Additionally, attacker can modify the page. The attacker is motivated to do so, as every tails user will connect there, whereas other arbitrary pages, there is no such motivation.
6. Users should be verifying ISO images via PGP.
7. Other connections that tails makes to check for updates, date, etc, (should) happen in other IsolateDestAddr circuits using (theoretically) more secure wget/curl etc.

As simple solution seems to be to just point to a local file as the homepage, as the Tor Browser currently does.

#11 Updated by techfx 2014-04-14 01:14:16

molibdeedee2 really hit the nail on the head with this one. The only reason I can see why Tails developers are persistent in not changing it is due to the anonymous metrics data they collect from that homepage.

But a question I have for the Tails developers is whether the anonymous stats they collect from the homepage worth it at the cost of putting all Tails users in jeopardy? The homepage being a remote site as opposed to a local file gives the adversery far too much intel.

We want to do everything we can to make it very difficult for the adversy. Whether they are doing traffic analysis or some other method, having all Tails users arrive at the same homepage upon connecting seems like we are going in the wrong direction when it comes to security and privacy.

The easiest and most privacy friendly solution would be to have a local html file with a heading stating “Tails Connected” and a few obvious links pointing to Tails News & Tor Check.

#12 Updated by sajolida 2014-04-14 06:45:21

> The only
> reason I can see why Tails developers are persistent in not changing
> it is due to the anonymous metrics data they collect from that
> homepage.
>
> But a question I have for the Tails developers is whether the
> anonymous stats they collect from the homepage worth it at the cost
> of putting all Tails users in jeopardy?

By the way, we don’t collect stats from the visits on that page. We only
collect stats on the security check that warns if new versions are
available. Note that this doesn’t happen in a browser but through a
command-line tool for fetching that page. And I definitely think this is
worth it in term of added security for the user.

See https://tails.boum.org/blueprint/faq#boot_statistics

#13 Updated by intrigeri 2014-04-14 06:45:32

> The only reason I can see why Tails developers are persistent in not
> changing it is due to the anonymous metrics data they collect from
> that homepage.

This is untrue. We don’t collect metrics from that homepage.

#14 Updated by t3x 2014-04-15 20:50:07

Since no stats are collected on the Tails homepage I honestly can’t see a logical reason to use a remote url instead of a local html file.

Can someone please explain where the logic is in giving the adversary more intel and making all Tails users upon connecting all arrive at the same location?

Just makes no sense to me when it comes to Tails users security and privacy to set one url that thousands and thousands of Tails users arrive at as their homepage.

#15 Updated by intrigeri 2014-04-16 09:36:44

> I honestly can’t see a logical reason to use a remote url instead of
> a local html file.

Please (re-)read comment 7.

(Don’t get me wrong: I’m not saying the current state of things is
perfect, I’m saying it solves an actual problem we had, and it would
be great if whatever other solution someone designs does not
reintroduce it.)

#16 Updated by sajolida 2014-06-28 08:28:51

Another proposal would be to set NoScript to block all JavaScript on our homepage by default.

#17 Updated by broncospasm 2014-09-20 23:18:58

…I was just gonna say, and sajolida beat me to it, and intrigeri beat the both of us to it with “meeting notes” mentioned above:

we could configure NoScript to block JavaScript on tails.boum.org,
and mitigate the concern about exploitation of the browser via JS on
the homepage; OTOH, not all firefox security issues require JS, so
it doesn't really solve much of the problem.

This would at least help. Some compromises are partial, and all an attacker can do is manage to insert javascript… and that could be enough. Personally, I think there should be a big fat warning about NoScript being OFF by default on whatever the “home page” is, but that’s probably for another discussion.

I think it would be a good compromise for now.

In spacey futuristic ideas, what about cryptosigning the home page and fetching it by RSS as part of browser launch, with a reasonable timeout (and a cache if persistence is enabled, maybe)? Then there’s only one connection.

I also think having the “home page,” if remote, be on a .onion might be something to consider for reasons similar to those I mention for switching DuckDuckGo search to the DDG .onion in Feature #6059: there’s no traffic over the clearnet, no jammed-up exit nodes to go through, and no delay from TCP 3-way handshake and latency between the exit node and the site. If DDoS can be mitigated or dealt with, having the home page on a .onion and denying Javascript on it doesn’t mitigate all risk if an attacker gains access to tails.boum.org, but it does mitigate some traffic/timing correlation attacks and lag IMO.

#21 Updated by intrigeri 2015-08-30 08:15:31

Passes encryption.feature, torified_browsing.feature, unsafe_browser.feature, windows_camouflage.feature.

#26 Updated by intrigeri 2015-09-16 12:41:02

Beware, I rewrote the history of this branch as the only change it carried was going to be reverted anyway.

#29 Updated by intrigeri 2015-10-05 05:22:07

> If our web server is compromised, the attacker could redirect us to another page (possibly on another domain) under its control that serves the attack, so the blacklist approach seems pointless to me. In fact, can’t the attacker just serve the JavaScript from another domain without a redirect?

Yes:

• if the attacker can reconfigure the webserver, then they can definitely serve whatever JavaScript they want;
• if the attacker got write access to our website only:
  • the redirect attack you’re describing works, but only because we’re allowing rewrite rules in htaccess; we could have this credential removed, and ask root@b.o to do such changes each time we need it, but it would be a bit painful;
  • not sure if JS from another domain would work (http://ikiwiki.info/plugins/htmlscrubber/ hopefully prevents such attacks, as long as we don’t disable this defense in depth feature (Feature #10299)).

> I thought this was why the blacklist approach in NoScript is pretty much worthless. If I’m right, I don’t thing there’s any point in merging this branch.

It could be made more useful (see above for what changes we would need) but the effort is probably not worth it. Better come up with a real solution, that is:

> It seems to me, again, that the issue is that there is a specific site that we automatically connect to with the browser.

Yes. Sorry for having wasted our collective time on it.

What we need is to think about our notification mechanisms: we have three partially overlapping systems (the browser homepage, the security notifications, and the Upgrader ones) that convey similar info in totally different ways. Some UX folks should sit down with Tails code/security people and think through what is the cheapest way to fix this security issue, at least without harming UX, and quite possibly improving it along the way.