Tails

#2 Updated by intrigeri 2015-03-07 09:56:07

Current state of my work:

• It builds and seems to work fine at first glance.
• I had to package Torbutton 1.9.0.0, thanks to our ISO-build-time check for the Torbutton version we install matching the one found in the Tor Browser tarball.
• The new “New circuit for this site” feature seems to work (the page is reloaded) but I didn’t check whether a new circuit was actually created and used. This might require Tor 0.2.6, no idea.
• I see the new security slider, but didn’t try it. In particular, one should check whether the persistent bookmarks feature still works even in levels higher than Low. Time to add automated tests in higher security levels?
• It would be good to do a full automated test suite run on an ISO built from the topic branch.
• The new Torbutton feature that displays circuits used by the current tab doesn’t work, presumably because we only allow Torbutton to issue a New Identity command on the control port. One should investigate if we can safely add whatever additional command is now needed to the whitelist.
• One should cautiously check that all our Tails-specific logics still works, e.g. search engine and homepage localization, since that’s what traditionally broken by such major upgrades.

#6 Updated by intrigeri 2015-03-20 21:50:35

We’ll need to set extensions.torbutton.show_slider_notification to false (see https://trac.torproject.org/projects/tor/ticket/9387).

#9 Updated by intrigeri 2015-04-27 05:23:47

I’ve broken the feature branch build today by trying to upgrade to 4.5-build5: our build system tries to fetch it from https://people.torproject.org/~mikeperry/builds//4.5/, while it lives in https://people.torproject.org/~mikeperry/builds/4.5-build5/. I guess that’s because the script extracts the subdirectory name from the tarball name, which isn’t correct in this case. Perhaps we should instead store the full path in tbb-dist-url.txt, and adjust a little bit our Tor Browser release process doc, so that we can support such cases?

#10 Updated by anonym 2015-04-28 01:45:45

intrigeri wrote:
> I’ve broken the feature branch build today by trying to upgrade to 4.5-build5: our build system tries to fetch it from https://people.torproject.org/~mikeperry/builds//4.5/, while it lives in https://people.torproject.org/~mikeperry/builds/4.5-build5/. I guess that’s because the script extracts the subdirectory name from the tarball name, which isn’t correct in this case. Perhaps we should instead store the full path in tbb-dist-url.txt, and adjust a little bit our Tor Browser release process doc, so that we can support such cases?

Yeah, this makes sense. Fixed in commit:8580ba8. The branch is unbroken, again.

#11 Updated by intrigeri 2015-04-28 02:24:54

> Yeah, this makes sense. Fixed in commit:8580ba8. The branch is unbroken, again.

Thanks!

#12 Updated by anonym 2015-04-28 11:57:40

Apparently there’s a couple Torbutton changes introduced for Tor Browser 4.5 that breaks the “New identity” feature vs. our control port filter (an automated test for this would have made me realize this a month ago instead of earlier today… hi Bug #9286!). I wasted hours debugging Torbutton’s complicated Javascript spaghetti to find what turned out to be the simple fact that our control port filter expects the control commands to be in uppercase, but Torbutton sends them in lowercase nowadays. Fixed in commit:385ff62.

However, I then found that it’s broken in a much worse way, but first, let’s note that Torbutton’s new circuit view (which is enabled by default) isn’t working for us, which is an issue in itself. To support it, Torbutton issues (on start) setevents streams on the control port, to asynchronously get all stream events so it can populate each tabs’ circuit view. Of course, our control port filter was designed with a simpler model, and doesn’t support this at all and will simply respond with a 510 error. However, it seems Torbutton isn’t designed to deal with such an error, so it keeps the connection open, blocking our filter’s port from further use… that is, it’s blocking the “New identity” feature from issuing its SIGNAL NEWNYM on a concurrent connection.

We have a couple of options to deal with these two issues:

Fix the control port filter, probably by using Whonix control-port-filter-python

Firstly, we must be able to deal with concurrent connections, and Whonix’ fork, control-port-filter-python, supports a configurable (but static) number of concurrent connections, so that would repair “New identity” feature (I’ve veirfied that it works in Tails (depends on python-gevent)).

To fix the circuit view, we’d then have to do something like a whitelist for events allowed to for setevents and then make it deal with the asynchronous nature of these events. This could get complex. It could be simplified by making that connection go into a “monitoring mode” for that connection, where no new requests are read (it’d only keep forwarding the events to the client) but unfortunately Torbutton will use the same control port connection that it issues setevents to to do other stuff, like GETINFO circuit-status. So, it’d have be fully asynchronous, which tends to get complex.

Also, if we do this, then the filter isn’t only allowing “safe” commands anymore; exposing the stream and circuit level info was IMHO part of why it seemed like a good idea in the first place.

Get rid of the control port filter, expose the control port to the amnesia user

This would of course be worse than the previous option by e.g. allowing GETINFO address and manual construction of compromised circuits.

Disable the circuit view on Tor Browser

I’ve verified that this one-line fix will make the “New identity” feature work again with our current filter.

So, among these options I think the simplest one, disabling the circuit view, is the best one for now. While losing the circuit view is a bit sad, but there’s no way we can have it without exposing fairly sensitive Tor state to the user running the browser, i.e. the amnesia user.

#14 Updated by anonym 2015-04-29 04:23:41

anonym wrote:
> So, among these options I think the simplest one, disabling the circuit view, is the best one for now. While losing the circuit view is a bit sad, but there’s no way we can have it without exposing fairly sensitive Tor state to the user running the browser, i.e. the amnesia user.

I’ll go with this for now, so we can get this merged ASAP (4.5 was released yesterday). If we still want to have the per-tab circuit view, we’ll open a new ticket. Done in commit:cbcdf12.

#15 Updated by intrigeri 2015-04-29 07:39:24

> However, I then found that it’s broken in a much worse way, but first, let’s note that Torbutton’s new circuit view (which is enabled by default) isn’t working for us, which is an issue in itself.

Right. I’ve reported it (Feature #9031#note-2) a month ago in the hope that we would have time to find a good solution in time for 1.4. Too bad, but no big deal.

> h3. Fix the control port filter, probably by using Whonix control-port-filter-python

That’s probably the best way to go long-term. Note that my initial review of that code highlighted quite a few issues. I might have been setting the bar too high, though, but it doesn’t look like code I would personally be happy to maintain on the long term in its current state.

> So, it’d have be fully asynchronous, which tends to get complex.

At this point, perhaps it should really use Stem. Otherwise we’ll be reinventing a few wheels.

> Also, if we do this, then the filter isn’t only allowing “safe” commands anymore; exposing the stream and circuit level info was IMHO part of why it seemed like a good idea in the first place.

Indeed, that would make things less tight. If we decide to go this way, we should analyze the security consequences.

> h3. Get rid of the control port filter, expose the control port to the amnesia user

No, please :) This would basically allow trivial de-anonymization by any exploited application running as the amnesia user.

> So, among these options I think the simplest one, disabling the circuit view, is the best one for now.

I (kinda sadly) agree that it’s what we should do for 1.4, given we’re seriously looking at it this late.

Please file tickets for the follow-ups: 0. research/discuss how much we want this feature (in the light of the upcoming replacement of Vidalia with Tor Monitor — IIRC the fact that this Tor Browser feature was upcoming was part of our reasoning); and then, if we want it: 1. analyze security implications of exposing the needed info to the amnesia user; 2. write the code needed to make it work.

I recommend looking at Feature #9031#note-2 again: there might be interesting stuff left to check in there.

#19 Updated by anonym 2015-04-29 17:32:43

intrigeri wrote:
> We’ll need to set extensions.torbutton.show_slider_notification to false (see https://trac.torproject.org/projects/tor/ticket/9387).

Agreed — nagging users each Tails boot isn’t good UX. However, I believe we should write end-user docs for this. It’s a bit late, but I created Bug #9297, optimistically targeting 1.4.

intrigeri wrote:
> > So, it’d have be fully asynchronous, which tends to get complex.
>
> At this point, perhaps it should really use Stem. Otherwise we’ll be reinventing a few wheels.

Definitely!

> > So, among these options I think the simplest one, disabling the circuit view, is the best one for now.
>
> I (kinda sadly) agree that it’s what we should do for 1.4, given we’re seriously looking at it this late.

Right. As already said, this was done in commit:cbcdf12.

> Please file tickets for the follow-ups: 0. research/discuss how much we want this feature (in the light of the upcoming replacement of Vidalia with Tor Monitor — IIRC the fact that this Tor Browser feature was upcoming was part of our reasoning); and then, if we want it: 1. analyze security implications of exposing the needed info to the amnesia user; 2. write the code needed to make it work.

I opened Feature #9298 for discussing if we want it, but I think a decision relies on an analysis of the security implications so I added something rudimentary to the ticket for background for the discussion.

> I recommend looking at Feature #9031#note-2 again: there might be interesting stuff left to check in there.

I’ve checked everything else:

• The security slider seems to work fine, including adding persistent bookmarks at each level.

• A run of the relevant .feature:s (those using any browser) went mostly fine, but showed a couple of issues with the chroot browsers, but these are only really issues for the Unsafe Browser due to to the affected features being disabled in the I2P browser:
  • The Unsafe Browser has disconnect.me as the default search engine in all locales. However, pre-4.5, e.g. in Tails 1.3.2, this is inconsistent depending on locale: in English we have startpage, in all others we have google.
  • Opening the Add-ons tab (about:addons) shows an XML parsing error (so the Starting the Unsafe Browser works as it should scenario in unsafe_browser.feature fails), that the button-plugin-disable CSS class is undefined. If I unpack the correct omni.ja and look at extensions.css I can see that it indeed isn’t defined. Strangely, if I install Torbutton into the chroot browser, then it works. Conversely, removing Torbutton from the Tor Browser reproduces the problem there (also in the vanilla Tor Browser, outside of Tails). Argh!? Note that despite this error, the langpacks and localization does work.

• As for the “Tails-specific logics”:
  • The correct default download directory is used (~/Tor Browser).
  • The LAN is accessible (yay! :)).
  • AdBlock Plus works.
  • No update check after an hour.
  • For localization and search plugins, I compared a build from this branch with Tails 1.3.2 in English, German and one more (can’t remember which) locale with support in the Tor Browser, and the only difference I noticed is that we have additional search plugins for disconnect.me and youtube.

Despite the two issues with the Unsafe Browser I think we should merge this. The default search engine issue should be fixed (I promise to do it before the final 1.4 release, but possibly after the RC). The issue with the Add-ons tab will probably be a nightmare to debug, and I do not think we should care. Using add-ons in the Unsafe Browser shouldn’t be encouraged, and we should probably hide its menu item like we do for the I2P Browser.

#20 Updated by intrigeri 2015-04-30 08:06:49

> The Unsafe Browser has disconnect.me as the default search engine in all locales.

I think that’s fine. Why do you think it’s a problem?

> Opening the Add-ons tab (about:addons) shows an XML parsing error (so the Starting the Unsafe Browser works as it should scenario in unsafe_browser.feature fails),

On the one hand, we don’t want users to install add-ons in the Unsafe Browser, so we could just not care. But that automated test seems definitely useful to me, so this sounds like a regression we want to fix.

> Despite the two issues with the Unsafe Browser I think we should merge this.

Please file a ticket for the about:addons bug, and request a review’n’merge for this branch, if you think it’s ready, then.

There’s also the search engine discrepancy wrt. the Tor Browser that bothers me a bit. See my email to tbb-dev@ earlier today. Please file a ticket for that one too.

> The issue with the Add-ons tab will probably be a nightmare to debug, and I do not think we should care. Using add-ons in the Unsafe Browser shouldn’t be encouraged, and we should probably hide its menu item like we do for the I2P Browser.

Why not, but… do we have another way to keep testing that the Unsafe Browser has no add-on enabled, if we do that?

#22 Updated by intrigeri 2015-05-01 00:50:40

> intrigeri wrote:
>> > The Unsafe Browser has disconnect.me as the default search engine in all locales.
>>
>> I think that’s fine. Why do you think it’s a problem?

> Perhaps it’s no issue since the search engine (except in If anything

Missing end of a sentence? I guess that part (found below) was replying on the default Unsafe Browser search engine topic:

> Right, it’s a change but perhaps we don’t care (OTOH, a search on disconnect.me raises more attention than a search on google, but that’s not a supported use case — startpage is also not good in that respect, though, I guess).

As far as the Unsafe Browser is concerned: for its intended use case, I expect most users to do a random web search to get the captive portal homepage. Wikipedia is probably slightly better than Disconnect in this respect, but I don’t think we can pretend we’re hiding the fact that one is using Tails’ Unsafe Browser in the current state of things.

>>> Opening the Add-ons tab (about:addons) shows an XML parsing error (so the Starting the Unsafe Browser works as it should scenario in unsafe_browser.feature fails),

>> On the one hand, we don’t want users to install add-ons in the Unsafe Browser, so we could just not care. But that automated test seems definitely useful to me, so this sounds like a regression we want to fix.

> However, I just noticed that it’s also true when the Windows Camouflage is enabled, which is a definitive regression.

I don’t understand what exact browser is affected by what problem when Windows Camouflage is enabled, given the confusion wrt. which topic you’re replying to. Please clarify.

> IMHO, the course of action, post RC probably, is:

> 1. Make sure “English Wikipedia” is selected when Windows Camouflage is enabled
> 2. Disable the add-ons menu item, like we do in the I2P Browser.
> 3. Change the test to use about:supprt to check that no extensions are enabled in the Unsafe Browser.

OK, modulo my comments and questions about the search engine and Windows Camouflage topics above.

>> There’s also the search engine discrepancy wrt. the Tor Browser that bothers me a bit. See my email to tbb-dev@ earlier today. Please file a ticket for that one too.

> I’m note sure what the ticket should be about. The situation is currently weird, since English has starpage, but all non-English locales has google. What is it we actually want here?

That’s exactly the question we need to discuss and resolve :) Note that I was talking of the Tor Browser in Tails, not of the Unsafe Browser. In the Tor Browser, we’re still default’ing to Startpage in all languages, while upstream Tor Browser has moved to Disconnect.

>> Why not, but… do we have another way to keep testing that the Unsafe Browser has no add-on enabled, if we do that?

> Yup, about:support. It will be a bit different (it will require scrolling down) but I have a good idea of how to do it.

Yay \o/

#28 Updated by intrigeri 2015-05-01 05:23:29

intrigeri wrote:
> > intrigeri wrote:
> >> There’s also the search engine discrepancy wrt. the Tor Browser that bothers me a bit. See my email to tbb-dev@ earlier today. Please file a ticket for that one too.
>
> > I’m note sure what the ticket should be about. The situation is currently weird, since English has starpage, but all non-English locales has google. What is it we actually want here?
>
> That’s exactly the question we need to discuss and resolve :) Note that I was talking of the Tor Browser in Tails, not of the Unsafe Browser. In the Tor Browser, we’re still default’ing to Startpage in all languages, while upstream Tor Browser has moved to Disconnect.

Created Bug #9309 so that it’s not forgotten when this ticket is marked as fix committed.