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

[Martin Uecker]

Hi Owen,

Owen Barton <owen at civicactions.com> wrote:

> 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?

It could be a different more secure server, a signed email
from a friend, it could be embedded in some other kind of document
transmitted in a secure way, a flyer with an QR code, some
other html page accessed again with a self-certifying URL.

I don't claim that it automatically solves all chain-of-trust problems,
but I think it would improve security in many scenarios in a very
simple way. 

There is another nice property: You could compare the hash with
other sources. If you download a trojaned binary over TLS
because the server was hacked or the crypto was broken,
you might never find out.

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

You are right, in this case it should be the same. Your argument about
3rd party links also makes sense. I guess both ideas could be very useful.

Martin


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