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

[Martin Uecker]

Patrick Mylund Nielsen <cryptography at patrickmylund.com> wrote:

> How do you apply to this to pages? Do you hash all their elements, or just
> the page? If it's the former: in what order do you do it? 

Just the page, the page could again have self-certifying links embedded.

> What if the
> author of a product decides to release a bug fix version? Your link will
> stop working, and make the software seem malicious when it's probably not.

The author would have to update the link. Many open source projects already
put hashes on their download pages or release notes, which need to be updated.
If this is too much work, there could be tools to help. Anyway, nobody would
be forced to use it...

In general, the solution to changing content is not to embedded a hash,
but the hash to a public key. The content would then be signed directly
or transmitted via a secure connection authenticated by this public key.
No CA necessary...

> How do you handle interstitial download pages? What about 302 redirects to
> specific versions of a binary? Not to mention media types that are
> autoplayed by browser plugins.

You raise a lot of valid points, but there is no reason to solve every
problem at once. 

Martin

BTW: This idea is not exactly new and many similar schemes have been
proposed/discussed in the past:

http://www.waterken.com/dev/YURL/
http://trevp.net/cryptoURL/
http://en.wikipedia.org/wiki/Magnet_URI_scheme
http://lists.w3.org/Archives/Public/www-talk/2001NovDec/0090.html
http://lists.w3.org/Archives/Public/www-archive/2008Apr/0065.html               

...and probably many more.


> I agree that it's interesting--probably the most appealing so far, but
> there are many common cases in which it would not work, or its behavior
> would be ambiguous. You'll also take on (/ take from the author) a fairly
> significant maintenance burden if you want to stay up-to-date with links
> directly to the latest versions (which probably have severe vulnerabilities
> patched) -- that is, of course, assuming your target host allows linking to
> files with an outside Referrer header.
> 
> 
> On Mon, Jul 1, 2013 at 9: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.
> >
> > Martin
> >
> >
> >
> > >
> > > Getting support in the browser or OS is critical, I agree - apart from
> > the
> > > convenience factor, installing a secondary "secure download" tool is a
> > > catch 22 for the user.
> > >
> > > - O
> > >
> > >
> > > On Mon, Jul 1, 2013 at 4:22 PM, Martin Uecker <uecker at eecs.berkeley.edu
> > >wrote:
> > >
> > > >
> > > > Jacob Appelbaum <jacob at appelbaum.net> wrote:
> > > >
> > > > ...
> > > >
> > > > > We need a secure downloading tool, we need it to be built into every
> > OS
> > > > > by default and until then, we'll have to rely on tricks to hack it -
> > > > > preloading certs in browsers, having a website to download it from
> > and
> > > > > so on.
> > > > >
> > > >
> > > > What we need are backwards compatible self-certifying URLs or
> > hyperlinks,
> > > > e.g. something like this:
> > > >
> > > > <a href="./mysoftware.tgz"
> > > > hmac="sha1:da19d18ef86f4fb8fe8b61323806ec1764f9bf00">My software</a>
> > > > <a
> > > >
> > href="./mysoftware.tgz#sha1:da19d18ef86f4fb8fe8b61323806ec1764f9bf00">My
> > > > software</a>
> > > >
> > > > And something similar to specify a public key.
> > > >
> > > > This would need to be standardized and supported by all major browsers.
> > > >
> > > > Martin
> > > >
> > > >
> > > > --
> > > > Too many emails? Unsubscribe, change to digest, or change password by
> > > > emailing moderator at companys at stanford.edu or changing your settings
> > at
> > > > https://mailman.stanford.edu/mailman/listinfo/liberationtech
> > > >
> > >
> > >
> > >
> >
> > --
> > Too many emails? Unsubscribe, change to digest, or change password by
> > emailing moderator at companys at stanford.edu or changing your settings at
> > https://mailman.stanford.edu/mailman/listinfo/liberationtech
> >