[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: concrete steps for improving apt downloading security and privacy

On 10 July 2014 18:07:59 CEST, Elmar Stellnberger <estellnb@gmail.com> wrote:

>In order to prevent unsuspecting users from downloading a compromised
>version of Debian I wanna propose the following:
>* promote the inclusion of Debian-public-keys in any free live CD sold
>with magazines and books:

I believe there is a copy of the key on the install cds? I don't see how getting a cd and a key from the same source really increases the trust level?

A better approach might be having the magazines publish their own key/fingerprint in every issue and then manually (with a face-to-face meeting) have the magazines sign the Debian key (s) and upload the signatures to the keyerver network.


>There is no sense in verifying a download with gpg unless you have
>fetched the public keys from a secure source.

You should be very careful when using the term "secure source" of public keys. A key is considered secure of it is trusted; it is considered trusted if it is signed by someone (many!) you trust: eg yourself or someone you know (and have the trusted key of).

Don't turn public crytography into secret key cryptography! Web-of-trust is a state of the art way to manage trust and key distribution!


>* https mirrors could in addition provide some additional security
>   - more privacy about the selection of packages you have downloaded

I think now, and for the forseeable future, many (most) mirrors are likely to be run by goverment sponsored/friendly institutions - and at any rate are likely to maintain traffic/access logs (in some jurisdictions this is mandated by law). Plain https does not protect (much) against a nation state level adversary.

Onion transports and local mirroring seem a better option if the goal is privacy. Even then, knowing that someone runs Debian and dates and filesizes of security updates might be enough to guess at installed packages/open vulnerabilities in a system?

>  - no deliberate delaying of new security updates (+ dnssec of course)

See above re:traffic analysis. I do think cron-apt could use some love/a better alternative?

>- secure download of individual packages on a non Debian machine for
>transport to an offline Debian machine

We already have this?

>- an additional security mechanism if some private keys should ever be
>stolen temporarily

Keys cannot be stolen temporary;  they are trusted or untrusted (revoked).

Speaking off - we could perhaps have a better ui for adding/revoking keys? With better support for web of trust and key severs?

>the current certificate authorization process is heavily compromised !!

Yes, I would also like to see a Debian CA set up - just because it would make sense to anchor trust of other ssl - infrastructure in the gpg-signed iso/dpkg distribution. As it is (as the ca certs are distributed the same as the rest of Debian) it only offers a secondary attack surface. You could be getting rogue ca certs the same way you could ne getting a backdoored libssl/kernel/etc.

The one benefit of the CA system is that cacerts are distributed by other os vendors as well. I think that is where a lot of this type of discussion is comming from. People would rather go to a website that windos xp saus is safe, in order to get Debian - rather than make an effort to verify the trust of Debian's various gpg keys.

Arguably we could do better with encouraging more user groups to do keysigning parties and education in order to make trust in gpg more easily viable for new users. 

As for "pinning" trust: one (not very rigorous) approach is to simpky assume you're not currently compromised (that is a necessary assumtion if you want to use gpg anyway) and sign the current Debian keys with your own gpg key (plaese do not upload such "leap-of-faith" signatures to the keyservers, though).

When you've done that, either:

1) you've signed a compromised key: at least if you discover that later, you know how far back you were (at least) compromised. 

2) You've trrusted a trustworthy key; you're safe until the next roll-over.

We could perhaps do a better job saying some of the above on the wiki/homepage? It's unfortunately unreasonable to assume most users are familiar with gpg and trust networks.



Ps: please trim and quote appropriately when posting to the list.

Reply to: