Hi Owen, Owen Barton <[email protected]> wrote:
> On Mon, Jul 1, 2013 at 6:28 PM, Martin Uecker <[email protected]>wrote: > > > Owen Barton <[email protected]> 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 -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
