Project

General

Profile

Feature #10122

Sign and download a single, merged upgrade-description file

Added by intrigeri over 4 years ago. Updated over 3 years ago.

Status:
Rejected
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
08/30/2015
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Upgrader

Description

Currently, we have one upgrade-description file per (Tails version, architecture, channel). This has at least two drawbacks:

  • Tails Upgrader leaks information (Tails version, architecture, channel) to our website, its sysadmins, and anyone who can break TLS. That's over Tor, no big deal, but still. [In passing, this "bonus" leaked information could actually be useful for us to get statistics about upgrade rate and latency, but I think this minor advantage isn't worth leaking more info than strictly needed -- the fact we're calling home is bad enough in itself, at least in terms of PR and the potential for attacks from our website against users, in case it becomes adversarial without us knowing; such info allows it to adjust the payload to the exact version of Tor Browser the user is running, given Tor Browser itself doesn't reveal that willfully, and our News page is its homepage.)
  • When releasing a new Tails, the RM has to sign a bunch of UDFs, which implies typing a PIN code numerous times, which is painful, needlessly increases the risk of locking the smartcard, and gives more opportunities than needed for an attacker to get the PIN code.

We could address those by slightly modifying the code (run by the RM) that generates the UDFs to generate a single, merged UDF. And accordingly, the client-side Tails Upgrader should be adapted to always fetch that merged UDF from the same location, and find out in its content the section it should take into account. All this sounds quite doable. It might be that the TBB does it this way already, see tools/update-responses/config.yml in its Git repo (but perhaps I'm wrong, it might be that this config file is merely used as input for another script that would generate split UDFs -- anyway).

The main concern I have about this idea is the size of the merged UDF file, and its impact on download time by Tails Upgrader (I'm assuming that bandwidth usage should be neglictible in front of our global website's bandwidth consumption). We may want to drop old upgrade descriptions from that merged UDF. Here's some data:

  • all current UDFs merged into a single file = 35kB => 3.2kB compressed with XZ; neglictible in front of a full Tor bootstrap, but some day we'll have persistent Tor state; neglictible in front of a partial Tor bootstrap (update) + Atom security feed size, as well? in any case, small enough to make the whole idea realistic
  • UDFs for the Tails releases we put out in the last 12 months (1.[1-9]*) = 25kB => 2.4kB compressed with XZ
  • UDFs for the Tails releases we put out in the last 6 months (1.[3-9]*) = 14kB => 1.4kB compressed with XZ

All in all, at least for the moment it seems that the benefit (in terms of download time) of dropping old upgrade descriptions isn't worth the effort. Note that if we merge UDFs, to start with, all previous Tails versions will go on checking for upgrades on the old URLs, so it would be useless to include their UDFs in the merged one. So, the merged UDF will be super small in the beginning, and only in a few years we'll need to consider expiring old ones. Whenever we do so, we'll need to ensure that the behavior is OK when starting a Tails whose UDF is not published anyway: in this case, we should instruct the user to manually check our website for upgrade instructions (probably using an OS and web browser that's less old and full of known security issues that such a super-old Tails).


Related issues

Related to Tails - Feature #10478: Do statistics on upgrade paths Resolved 11/04/2015
Related to Tails - Feature #7726: Have upgrade-description files expire Confirmed 08/02/2014

History

#1 Updated by intrigeri over 4 years ago

Leaving this as New until anonym and sajolida have ack'ed the general concept. Low priority, I won't commit to work on it, but who knows what can happen... I had the idea while procrastinating on non-Tails stuff :)

#2 Updated by sajolida over 4 years ago

I'm not against doing that though the cost/benefit doesn't make it a big issue to me.

#3 Updated by intrigeri about 4 years ago

#4 Updated by intrigeri about 4 years ago

  • Related to Feature #7726: Have upgrade-description files expire added

#5 Updated by intrigeri over 3 years ago

  • Status changed from New to Confirmed
  • Assignee set to anonym
  • QA Check set to Info Needed

anonym, do you think we should keep this open?

#6 Updated by anonym over 3 years ago

  • Status changed from Confirmed to Rejected
  • Assignee deleted (anonym)
  • QA Check deleted (Info Needed)

intrigeri wrote:

anonym, do you think we should keep this open?

Not really. If we really care at some point, when can reopen/recreate this ticket. => Rejecting.

Also available in: Atom PDF