Tails

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).