Am 11.07.2014 um 02:55 schrieb Eirik Schwenke: > On 10 July 2014 18:07:59 CEST, Elmar Stellnberger <estel...@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?
The trust level does not depend on whether the key is on CD or not but on how you have obtained your CDs: a.) via snail - mail -> trust level gamma: The NSA is known to intercept postal items like purchased CD-sets or whole computers in order to install bugs. b.) via your private internet access -> trust level gamma: If the NSA is interested in you for some kind of reason your current OS-installation will already be compromised (and all the private gpg keys you have) c.) anonymously in a news paper shop -> trust level AAA: The NSA is known not to spill their attack vectors with the watering can because every usage of an attack vector may reveal it to the harm of these agencies So what we can trust in is c.). … and it won`t make a difference if the magazine has downloaded the Debian public keys via http on a Windows client because anyone involved in Debian would see immediately that a compromised key has been publish (i.e. that would cause a big damage to an intelligence service behaving as stupid as that). What you will have to do is * make magazines publish your public keys (or entire Debian/SystemRescueCD or other installation media which include these public keys) * change them regularly > > 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. No face-to-face necessary; just an anonymous source of distribution! That web-of-trust discussion is somewhat flawed; it will never work in practice. > > (...) > >> 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! Don`t be picky with words! If you prefer the more correct term trusted key then this is o.k.. However a trusted key should be secure to use. > > (...) > >> * https mirrors could in addition provide some additional security >> including >> - 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. … and I believe you are basically right. However the NSA would still hardly temper a university mirror directly. They prefer to have their own mirror servers and promote them via DNS-poisoning / faster response times. > > 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? unnecessarily complicated and expensive. Because of the fact that not everyone uses it users of Tor servers are targeted specifically by the NSA. So this is not an option either. > >> - 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? This is not an answer to the question I have raised. That is an issue, certainly, because the gpg web of trust can not guarantee you being connected to the right machine and thus guarantee you fetching the latest greatest updates. Only DNSSEC/DANE can guarantee that up to a given level. Gpg web of trust as used by package signatures is great when you want to verify that your packages come from the right source but it fails to prove their actuality at the current state of implementation. > > >> - an additional security mechanism if some private keys should ever be >> stolen temporarily > > Keys cannot be stolen temporary; they are trusted or untrusted (revoked). Yes but that forces you to re-issue another key. Please do not split hairs on my mode of expression / the words I use. > > Speaking off - we could perhaps have a better ui for adding/revoking keys? > With better support for web of trust and key severs? No that is not what I mean. If the communication is secured by two different keys ( a certificate and signatures ) then one of them can get stolen and you are still safe. see also: the anonymity paradox mentioned in the first lines of this response against your 'web of trust' approach which is seriously flawed for practical purposes. > >> 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. A new Debian CA could be subject to the same flaws as traditional CAs. > > 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). .. and this is a wrong assumption. I believe that most Debian developers use web browsers on their machines and visit unsecured/untrusted sites over these browsers. Consequently their private keys can be stolen easily at any given point in time. > > 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. > bla bla bla. What could improve security is a wider use of DNSSEC/DANE also for mirrors. It is not a silver bullet but it solves so many issues with current CAs and the gpg 'web of trust' which does not apply in practice. > > > -eirik > Elmar
