Tails

The current security design of incremental upgrades currently allow for “Rollback attacks”, “Indefinite freeze attacks”, “Wrong software installation” and “Vulnerability to key compromises”, if an attacker can replace upgrade-description files with (e.g. older) other ones. To conduct such an attack, one currently needs to either change the content in the main Tails Git repo (but that would be noticed, most likely), or to control the files served by our website, or to break the TLS connection between tails-iuk-check-upgrade-description-file and https://tails.boum.org/.

This class of problems could be fixed relatively easily by including a valid_before field in the (signed) upgrade-description files, that tails-iuk-check-upgrade-description-file would then verify against the current date and time.

This idea was not included in the initial design of Tails incremental upgrades for several reasons:

1. even without it, incremental upgrades were believed to be at least as safe as the previous upgrade system against such attacks; so, it seemed to be good enough for a first iteration;
2. having to periodically update upgrade-description files on our website appeared to add too much work on our shoulders, with too grave consequences if, for some reason, we forget or are unable to do it.

The first point is still valid, but it should not prevent us from improving things now that the first iterations were successfully completed.

The second point is still a concern: automating this process would require to have a very strongly trusted system on the Internet, that pushes these updates to our website; I don’t believe that our infrastructure/sysadmin team can handle that much pressure currently. However, what we could do is to have the upgrade-description files, that are generated when preparing a Tails release, be valid for two release cycles, that is 12 weeks (plus a few days to be on the safe side, possibly). This way:

• even if we skip a release, upgrade-description files don’t expire too early, and then don’t need to be manually refreshed;
• (almost) no work is added to the release process;
• we can validate this idea and its implementation without too much initial pressure. We can even mess up a little bit, in certain affected areas, without causing any harm.