[liberationtech] secure download tool - doesn't exist?!?

[Owen Barton]

On Mon, Jul 1, 2013 at 6:28 PM, Martin Uecker <uecker at eecs.berkeley.edu>wrote:

> Owen Barton <owen at civicactions.com> wrote:
>
> > This is roughly what I was suggesting with the http header (fetching the
> > hash with a TLS HEAD request even if the download itself is not TLS). I
> > think this may be preferable to encoding the hash with the link, as it
> > would work even with 3rd party links.
>
> This has weaker security properties.
> The user has to trust:
>
> - everybody who has access to the server
> - that the server has not been compromised
> - a CA has not been compromised
> - TLS is working correctly
>
> - the source of the link
>
>
> Compare this with self-certifying links: Having the hash in the
> link guarantees that you got exactly the file the link specifies.
> This secures an easy-to-understand and fundamental property of
> a link. The user only has to trust the source of the link.
>

Fair enough - however for this to be true, the self-certifying links need
to be both stored and transmitted without using any server (that the user
doesn't already directly and exclusively control) or using TLS and CAs. How
do you propose users locate download links for software that follows these
conditions?

I was assuming that most users would follow the practice of accessing a
download link off a project page (via https), or perhaps via a software
repository. In this case, it seems to me that a the self-certifying link
has exactly the same security properties as a http header.

That said, I totally agree there is a difference between trust of the link
author and trust of the download server. Self-certified links would be
better if you get a download link via a secure channel from an individual
you trust, or from a repository of links you are already implicitly
trusting (for example an OS that builds from original sources). They also
better allow for mirroring and other distribution strategies, which I think
is an important benefit.

Thanks!
- Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130701/329b2cc8/attachment.html>