Chris's Wiki :: blog/web/HttpsAndDownloads Commentshttps://utcc.utoronto.ca/~cks/space/blog/web/HttpsAndDownloads?atomcommentsDWiki2015-04-11T19:29:06ZRecent comments in Chris's Wiki :: blog/web/HttpsAndDownloads.By Chris Siebenmann on /blog/web/HttpsAndDownloadstag:CSpace:blog/web/HttpsAndDownloads:15272f91d90bea8f582648a6854a0f3965358cb1Chris Siebenmann<div class="wikitext"><p>I disagree very strongly with your view that HTTPS for downloads is
a waste of cycles in general. The practical reality is that very few
people will securely obtain your PGP key and go through the effort of
PGP-verifying your signed collection of hashes by hand. I expect that
almost everyone simply downloads things and just installs them; as a
result a non-HTTPS download gives them no security.</p>
<p>Some will now say that those people who didn't verify downloads with
carefully obtained PGP keys don't really care about security and
deserve the lack of security that they get. This is wrong. As always,
<a href="https://utcc.utoronto.ca/~cks/space/blog/tech/SecurityIsPeople">security is people</a>, not mathematics; if
actual people are not using your download system securely, you have
not created a secure system. <a href="https://utcc.utoronto.ca/~cks/space/blog/tech/SocialProblemsMatter">You have not solved the real problem</a>, you've just washed your hands of it.</p>
<p>HTTPS is a mess. HTTPS has flaws. But for most download situations
HTTPS is <em>unambiguously</em> better than non-HTTPS, and you should be
using it.</p>
<p>(As a side note, you can safely switch to non-HTTPS downloads if your
initial bootstrap is delivered over HTTPS and it automatically verifies
those non-HTTPS downloads, rejecting anything that fails.)</p>
</div>2015-04-11T19:29:06ZBy Joshua M. Clulow (Joyent) on /blog/web/HttpsAndDownloadstag:CSpace:blog/web/HttpsAndDownloads:3b26387de5283679a872d8819e701f04c9f298fcJoshua M. Clulow (Joyent)<div class="wikitext"><p>I emphatically do not agree that everything needs to be over HTTPS. It is, frankly, a waste of cycles to encrypt the bulk downloads themselves. Rather, signing the download with a PGP key is not just sufficient, it actually provides real security and not just a feeling of security.</p>
<p>The HTTPs trust model is pretty bad. Many organisations inject their own certificates into the trust stores of corporate machines so that they may sniff (and modify) traffic from workstations and servers. Laptop manufacturers have even been caught doing it, <a href="http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/">as recently as this year</a>. If a Certificate Authority (CA), <a href="http://techcrunch.com/2015/04/01/google-cnnic/">even by accident</a>, signs a domain without correctly verifying identity then they are instantaneously a gaping, difficult-to-detect hole in the trust chain.</p>
<p>I agree that telling users to find our PGP key on the unsecured front page along with all of the other materials is not our best foot forward. What we do with Node is considerably better: we sign <a href="http://nodejs.org/dist/latest/SHASUMS.txt.asc">a manifest of SHA signatures</a> of all distributable files using the key of the current release manager. This key is available via several third party services, such as <a href="https://keybase.io/tjfontaine">keybase.io</a>, where the user is encouraged and expected to get it. The trust chain is explicitly not something we provide solely through our website, but indeed a larger set of infrastructure owned by multiple parties. People who download more than one Node release can use their previously obtained copy of the key material, in the same way that SSH stores host fingerprints, for an additional layer of protection.</p>
<p>We should absolutely push for better integrity of downloaded software, but HTTPS is not an appreciable increase in real security -- just security theatre.</p>
</div>2015-04-11T17:17:07ZBy Albert on /blog/web/HttpsAndDownloadstag:CSpace:blog/web/HttpsAndDownloads:c0ac0c2d8f6d1c923a08d06e6b71ba47441bdd43Albert<div class="wikitext"><p>Well, usually PGP keys are (on purpose) widely distributed and can be downloaded and cross-checked from multiple sources. It would be quite hard for an attacker to compromise them all.</p>
</div>2015-04-09T07:57:44ZFrom 84.167.208.105 on /blog/web/HttpsAndDownloadstag:CSpace:blog/web/HttpsAndDownloads:38b80fa827040d4aff806989f02fe2c84f31535aFrom 84.167.208.105<div class="wikitext"><p>Comment on the discussion from a Kali developer.</p>
<p><a href="https://lwn.net/Articles/637994/">https://lwn.net/Articles/637994/</a></p>
</div>2015-04-08T17:13:44ZBy Chris Siebenmann on /blog/web/HttpsAndDownloadstag:CSpace:blog/web/HttpsAndDownloads:b8de5574d1d2769cff28391b8cdbbf1c485ff151Chris Siebenmann<div class="wikitext"><p>The reply in RISKS 28.58 is dangerously incomplete; how do you securely
obtain the initial package signing key for Kali? If everything is
distributed over HTTP instead of HTTPS, the answer is 'you don't'; an
attacker can compromise the initial copy you download to have their
key instead of the real key, then just sign all further (compromised)
packages you get with that key. This is effectively just like what
Joyent is doing when they provide the PGP key ID to use for verification
on an insecure web page.</p>
<p>(A clever attacker might be able to give you both their key and the real
Kali key, so they can mostly let you use real packages and real mirrors
but substitute a compromised one whenever they feel like.)</p>
</div>2015-04-08T16:03:25ZBy Albert on /blog/web/HttpsAndDownloadstag:CSpace:blog/web/HttpsAndDownloads:c86c7f4c7d744346b2b5e7f5e06869a625ac8523Albert<div class="wikitext"><p>This was discussed recently on the RISKS mailing list:</p>
<p><a href="http://catless.ncl.ac.uk/Risks/28.56.html#subj20">http://catless.ncl.ac.uk/Risks/28.56.html#subj20</a> (original message, complaining about mostly the same thing)</p>
<p><a href="http://catless.ncl.ac.uk/Risks/28.58.html#subj13">http://catless.ncl.ac.uk/Risks/28.58.html#subj13</a> (answer)</p>
</div>2015-04-08T08:04:22Z