Bug #12645

FAQ: Explain why we don't give a SHA of the ISO image

Added by sajolida 2017-06-06 16:49:40 . Updated 2018-05-31 15:38:51 .

Status:
Resolved
Priority:
Low
Assignee:
Category:
Target version:
Start date:
2017-06-06
Due date:
% Done:

0%

Feature Branch:
Type of work:
End-user documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

This has been a frequent question for a while…

See:

- Feature #11552#note-1
- Feature #11623#note-2

Keywords: SHA, checksum, hash.


Subtasks


Related issues

Related to Tails - Feature #11552: Add sha256sum Rejected 2016-06-29
Related to Tails - Feature #11623: Provide SHA-Checksum and HTTPS Download Rejected 2016-08-06
Related to Tails - Feature #12630: Document how users can verify a reproducibly built ISO/IUK Resolved 2017-06-02
Has duplicate Tails - Feature #11977: FAQ: Why we don't provide a checksum anymore Duplicate 2016-11-21
Blocks Tails - Feature #15411: Core work 2018Q2 → 2018Q3: Technical writing Resolved 2018-03-14

History

#1 Updated by sajolida 2017-06-06 16:49:56

#2 Updated by sajolida 2017-06-06 16:50:03

  • related to Feature #11623: Provide SHA-Checksum and HTTPS Download added

#3 Updated by cbrownstein 2017-06-12 21:51:19

I’m happy to take on this ticket, but first, I need some input to understand exactly why SHA checksums are no longer provided.

I’ve read sajolida’s note in Feature #11623:

> Regarding checksum. We removed checksum verification last year because we couldn’t find a way to document how to use these checksum easily on Windows, Mac, and Linux (we tried for many years before that and failed). Right now we provide three techniques for verification (Firefox extension, BitTorrent, and OpenPGP) which are equivalent and sometimes superior to checksum. People like you who are technical enough to already do checksum verification on their favourite OS are probably technical enough to rely on BitTorrent or OpenPGP verification if they don’t like the Firefox extension (which I can understand).

I understand the difficulty reason pointed out in that note. It’s the verification reason I’m not quite understanding.

PGP verification makes sense to me. Tails ISOs are signed by the Tails signing key. The Tails signing key can be authenticated through the web of trust: the Tails signing key is signed by individuals I already trust, so I trust that the Tails signing key I’ve downloaded is the real Tails signing key. This method of verification, through PGP, holds up if the Tails website is compromised.

I imagine the verification reason SHA checksums are no longer provided is because if the Tails website is compromised, a fake checksum could be substituted for the real checksum. If that happens, a modified ISO could appear to be legitimate.

Based on my understanding of how BitTorrent works, it also is not a trustworthy method to verify the integrity of a Tails ISO. If the Tails website is compromised, couldn’t the attacker replace the real .torrent file with a malicious one?

(I have no experience with the Firefox extension so I can’t comment on it.)

Hopefully I’m not too off the mark here.

#4 Updated by cbrownstein 2017-06-12 21:52:20

  • QA Check set to Info Needed

#5 Updated by sajolida 2017-06-13 11:54:33

  • Assignee set to cbrownstein
  • QA Check deleted (Info Needed)

It’s good that you make sure to understand the issue well before start with your draft :)

Your security analysis is right so far. The basic assumption here is that, unless people have previous knowledge of how to do the web-of-trust verification, they will always depend on the instructions or on the data on our website to perform the verification, and thus on the encryption and authentication provided by HTTPS:

  • If you use OpenPGP without the web-of-trust, you download our signing key over HTTPS and use it to verify.
  • If you use BitTorrent, you download the Torrent file from our website and your BitTorrent client will do a checksum verification at the end of the download.
  • If you use the Firefox extension, the extension will fetch a ISO Description File (IDF) from our website and do a checksum verification at the end of the download.

It might sound a bit overkill to provide these techniques to only get something as trustworthy as HTTPS but in the context of downloading Tails they make sense:

  • We don’t have the infrastructure to provide all downloads ourselves and rely on third-party mirrors for capacity. On the other end our website is much more trusted.
  • On top of the encryption and authentication provided by HTTPS we also want to check the integrity of the downloads: that they are complete and that there was not bug in the download.

So providing a checksum on our website would bring the same level of security (not more not less) and we don’t want to clutter our installation and download instructions with yet another method while, in terms of usability, we couldn’t find easy ways to document how to verify the checksum in a way that is cross-platform.

Still, many power users bother us with “GIVING THE SHAAAA!” but our opinion is that this public should do BitTorrent or learn basic OpenPGP.

Hopefully, things will get better if we manage to port the Firefox extension to Chrome and cover more public this way.

Do you need to know anything else?

I’ve done way too much technical writing this year already and want to focus on doing more UX in the coming months. So I won’t be very proactive on this front but I’ll still be very happy to provide input and review your work :)

#6 Updated by sajolida 2017-06-13 11:56:33

  • has duplicate Feature #11977: FAQ: Why we don't provide a checksum anymore added

#7 Updated by sajolida 2017-06-13 11:57:41

  • Subject changed from Explain why we don't give a SHA of the ISO image to FAQ: Explain why we don't give a SHA of the ISO image
  • Description updated

#8 Updated by cbrownstein 2017-06-13 22:13:11

sajolida: Thank you always for your guidance. :-)

I believe I understand the issue now.

The compromised Tails website scenario concerned me because the website for a Linux distro, namely, Linux Mint, has in the past been compromised.

http://blog.linuxmint.com/?p=2994

In that case, a backdoor was inserted in a modified ISO.

#9 Updated by cbrownstein 2017-06-27 08:19:20

  • Assignee changed from cbrownstein to sajolida
  • QA Check set to Info Needed

#10 Updated by Anonymous 2017-06-27 08:20:42

  • related to Feature #12630: Document how users can verify a reproducibly built ISO/IUK added

#11 Updated by Anonymous 2017-06-27 12:36:55

  • Starter deleted (Yes)

I think that it would be worthwile to explain why we don’t give the SHA and why people should not rely on it. And then we can point to the reproducible builds verification method, see Feature #12630? Could this be added to the FAQ?

#12 Updated by sajolida 2017-07-10 18:12:12

  • Assignee changed from sajolida to cbrownstein
  • QA Check deleted (Info Needed)

@cbrownstein: I’m also very concerned about a hypothetical compromision of our website. The thing is that, if this was to happen, all verification techniques would basically be game over (expect a careful web-of-trust verification). So we have to discard this option for all the more simplistic verification technique which are still desperately needed by a vast majority of our audience.

@u: We are not providing a checksum not because of trust issue (it would be as trustworthy as DAVE or BitTorrent) but for the sake of simplicity as we are already offering 3 equivalent techniques and also because checksum verification wouldn’t cover a very interesting audience (we tried for years to provide an easy and graphical way of doing it but failed).

#13 Updated by Anonymous 2018-01-17 11:55:14

Ok so I guess that cbrownstein will still need to know where to add this draft?

#14 Updated by cbrownstein 2018-01-20 22:08:47

  • Assignee changed from cbrownstein to sajolida
  • QA Check set to Info Needed

Here’s what I have:

Where can I find the SHA hash to verify my Tails download?

We do not provide a SHA hash to verify your Tails download. Verification using
a SHA hash is no better than verifying using our download extension,
BitTorrent, or OpenPGP. These verification methods all rely on some information
being securely downloaded from our website using HTTPS. Similarly, verification
using a SHA hash would rely on the hash being securely downloaded from our
website. In order to verify your ISO download without having to rely on some
information being securely downloaded from our website, you need to use [OpenPGP]
and [authenticate our signing key] through the OpenPGP Web of Trust.

The bracketed language would be linked to:

https://tails.boum.org/install/download/index.en.html#install-inc-steps-download.inline.basic-openpgp

and

https://tails.boum.org/install/download/index.en.html#install-inc-steps-download.inline.web-of-trust

N.B. Feature #14788 will have to be resolved before the above links will work.

#15 Updated by sajolida 2018-02-16 21:23:35

  • QA Check changed from Info Needed to Ready for QA

Marking as “Ready for QA” because Cody sent a draft.

#16 Updated by sajolida 2018-05-04 15:19:39

  • Target version set to Tails_3.7

#17 Updated by sajolida 2018-05-04 15:19:49

  • blocked by Feature #15411: Core work 2018Q2 → 2018Q3: Technical writing added

#18 Updated by sajolida 2018-05-04 15:19:53

  • blocks deleted (Feature #15411: Core work 2018Q2 → 2018Q3: Technical writing)

#19 Updated by sajolida 2018-05-04 15:19:57

  • blocks Feature #15411: Core work 2018Q2 → 2018Q3: Technical writing added

#20 Updated by sajolida 2018-05-04 19:27:49

  • Assignee changed from sajolida to cbrownstein

I imported your draft in Git and improved it a little bit. Please review doc/12645-no-sha.

#21 Updated by bertagaz 2018-05-10 11:09:19

  • Target version changed from Tails_3.7 to Tails_3.8

#22 Updated by cbrownstein 2018-05-13 00:43:54

  • Assignee changed from cbrownstein to sajolida
  • QA Check changed from Ready for QA to Pass

Looks good!

#23 Updated by sajolida 2018-05-15 10:16:06

  • Assignee deleted (sajolida)
  • QA Check deleted (Pass)

Merged, thanks!

#24 Updated by sajolida 2018-05-31 15:38:51

  • Status changed from Confirmed to Resolved