Toward secure package downloads

Posted Mar 26, 2015 8:42 UTC (Thu) by rhertzog (subscriber, #4671)
Parent article: Toward secure package downloads

Hello,

I am a Kali Linux developer, I have read the whole discussion and concluded that there was not much for Kali to improve.

http.kali.org, security.kali.org, cdimage.kali.org uses HTTP but they are mirror redirectors and they redirect users to external mirrors outside of our control. That's why the only protection that we offer is through GPG signature verification. Our public archives do contain GPG signed checksums of the files (consumed by apt-get for the package mirrors, or to be used manually by end-users downloading ISO files, cf the instructions on http://docs.kali.org/introduction/download-official-kali-...).

And to obtain the public GPG key, you are instructed to download it over https at https://www.kali.org/archive-key.asc The fingerprint of that key is also available over https. And the key is signed by myself and a few other developers, and I am in the global web of trust since my key is reasonably well connected (much like all keys of Debian developers).

For the record, we will enable HSTS on www.kali.org as this has been suggested. We were already redirecting http requests to https, so it's a small step further. We don't plan on requesting certificate pinning in browsers.

If you have any other suggestion of things that we can improve, please send them to devel@kali.org and we will consider them.

(Log in to post comments)

Toward secure package downloads

Posted Apr 7, 2015 14:07 UTC (Tue) by thestinger (guest, #91827) [Link]

> http.kali.org, security.kali.org, cdimage.kali.org uses HTTP but they are mirror redirectors and they redirect users to external mirrors outside of our control. That's why the only protection that we offer is through GPG signature verification.

The torrent file or a magnet link could be hosted on kali.org and would provide a full chain of trust without user intervention via the torrent's SHA1 hashes. It's tiny so there's no real need for that to be provided via mirrors.

Users would still benefit from validating the download via the GPG web of trust, but they wouldn't really gain anything by doing it via a key obtaining via HTTPS as there won't be a break in that chain of trust.

> For the record, we will enable HSTS on www.kali.org as this has been suggested. We were already redirecting http requests to https, so it's a small step further. We don't plan on requesting certificate pinning in browsers.

By the way, setting the preload option in the HSTS header is all that's required for getting on the browser preload lists. It can then be submitted via this web form:

https://hstspreload.appspot.com/

Doing HSTS preloading has very little risk, unlike pinning which involves being very careful about managing the certificate life cycle.

> If you have any other suggestion of things that we can improve, please send them to devel@kali.org and we will consider them.

Well, might as well try here first :). Others might benefit from the response.