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

[Patrick Mylund Nielsen]

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

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130701/057a2638/attachment.html>