Re: concrete steps for improving apt downloading security and privacy
Thanks, but if you will notice, I have that link already listed at the bottom of my message. Also, you should not respond directly to people unless they specifically ask you to do so. I did not ask. On Wed, Jul 9, 2014 at 11:52 PM, Reid Sutherland r...@vianet.ca wrote: https://www.debian.org/ Go to CD ISO Images, then Verify. On Jul 10, 2014, at 12:24 AM, Kitty Cat realizar.la@gmail.com wrote: Thanks. I'm new here. I was not on this list then. However, I just read the thread: https://lists.debian.org/debian-security/2011/01/msg2.html I saw that some of my concerns were mentioned there about obtaining and verifying installation media, MITM attacks, etc. I have previously verified installation media via the methods described in the FAQ, downloading GPG keys, etc. and still had an issue of having aptitude telling me that all available packages are from untrusted sources. (This was some years ago when I had this issue) I seem to remember being offered security updates for the kernel, OpenSSL, SSH, etc. where my only option was to download untrusted packages. I would get warning messages from aptitude about installing security updates. Maybe there should be written a document that describes in detail in easy to understand language what steps to take to verify keys and verify that apt has not been compromised in an already installed system. And also verifying that GPG has not been compromised. It is the job of the NSA to be able to compromise systems. We should make that task as difficult as possible at every level and also be able to easily verify that our system has not been corrupted. I think having a good guide to checking your installed Debian system would be of use. Particularly useful would be instructions to check to see if your system has been compromised by validating all already installed packages. MS Windows has an option to check installed Windows components. Some relevant links that I have previously discovered: https://wiki.debian.org/Keysigning https://wiki.debian.org/Keysigning/Coordination http://www.debian.org/CD/verify http://www.debian.org/CD/faq/#verify On Wed, Jul 9, 2014 at 8:11 PM, Michael Stone mst...@debian.org wrote: On Wed, Jul 09, 2014 at 06:29:09PM -0600, Kitty Cat wrote: For years I have been concerned with MITM attacks on Debian mirrors. We discussed this literally within the past couple of months on this list, at length. Have you read the archives, including the posts about how to establish a trust path to the ISOs? Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140710021124.ga27...@mathom.us
Re: concrete steps for improving apt downloading security and privacy
2014-07-07 12:13 GMT-08:00 Andrea Zwirner and...@linkspirit.org: Can you proof it? Or maybe, you can tell the list what the attached image - that is encrypted with Moritz Muehlenhoff's and Florian Weimer's public keys - represent? Cheers (and thanks Mr. Moritz and Mr. Florian - who were the only I had in my keyring - to accept being the judges of the challenge). :-) I am very new with crypto, but I do not think he will be able to prove it with cryptography such as is used in modern browsers, maybe in ECB mode as described here: http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic%20codebook%20%28ECB%29 HTTPs hardly solves any problem with state-level monitoring, I don't think, after all, CAs can be compelled to produce certs, or even compromised (e.g. http://googleonlinesecurity.blogspot.co.nz/2014/07/maintaining-digital-certificate-security.html ) Implementing cert pinning OTOH, that might be better.
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 09, 2014 at 10:24:18PM -0600, Kitty Cat wrote: I seem to remember being offered security updates for the kernel, OpenSSL, SSH, etc. where my only option was to download untrusted packages. I would get warning messages from aptitude about installing security updates. Probably a configuration error. This should be rare with the current defaults, and would be worth a question before proceeding to install untrusted packages. Maybe there should be written a document that describes in detail in easy to understand language what steps to take to verify keys and verify that apt has not been compromised in an already installed system. And also verifying that GPG has not been compromised. You can't. There's a long answer, but the short answer is that it isn't practically possible. of use. Particularly useful would be instructions to check to see if your system has been compromised by validating all already installed packages. MS Windows has an option to check installed Windows components. Which is useless in real-world terms. If it wasn't, we wouldn't see windows botnets. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9571e786-082e-11e4-b7eb-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 09, 2014 at 11:56:43PM -0400, Darius Jahandarie wrote: Someone who is unwilling to click past the first link /now/ may become very willing to continue clicking once they read it. Debian will not protect you against nation-state adversaries is a very useful bit of information for many non-technical activists, which often leads to the questions: * Why? (what powers can they use to subvert existing protections?) * What /does/ protect you? (what new protections need I put in place such that those powers cannot subvert them?) It would be lovely to have the answers nearby. Feel free to start writing. I challenge you to point to any OS with a simple, useful, and reliable guide to protect against a determined and well funded adversary. Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/fee48c46-082e-11e4-8bb2-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
Now; I believe there are several things Debian could do to improve security. 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: http://www.sysresccd.org/forums/viewtopic.php?f=6t=5208 There is no sense in verifying a download with gpg unless you have fetched the public keys from a secure source. * preinstall the DNSSEC/DANE plugin at least for Firefox by default. That may even warn the unsuspecting user when downloading an iso from an untrusted source. Even for an expert user there is no sense in downloading the root DNSKEYs from an untrusted source via the traditional https certificate chain. * include secure checksums in *every* package header (not just for a majority of packages) for every file in the package and use sha256/512sums instead of the compromizable md5sums This could leverage checking your Debian installation by another boot medium later on see for (x) at the bottom with tools like debsums or better debcheckroot (https://www.elstel.org/debcheckroot/) * https mirrors could in addition provide some additional security including - more privacy about the selection of packages you have downloaded - no deliberate delaying of new security updates (+ dnssec of course) - secure download of individual packages on a non Debian machine for transport to an offline Debian machine - an additional security mechanism if some private keys should ever be stolen temporarily !! in order to make this meaningful all these https mirrors would need to offer DNSSEC/DANE in addition because the current certificate authorization process is heavily compromised !! That was rather an exception: http://googleonlinesecurity.blogspot.co.nz/2014/07/maintaining-digital-certificate-security.html This is really causing problems when not using DNSSEC/DANE: http://webmasters.stackexchange.com/questions/35597/how-to-find-domain-registrar-and-dns-hosting-with-good-dnssec-support (x) That may be even more important since you can also be compromised later on via the browser and a backdoor kernel system call which allows the intruder to become root and exchange your key bundle. Moreover even the private keys could be stolen temporarily. Am 10.07.2014 um 02:29 schrieb Kitty Cat: For years I have been concerned with MITM attacks on Debian mirrors. I think the only valid solution would be to individually sign EACH package with a valid GPG signature from a trusted source. I think EACH official package from Debian should be GPG signed by both package maintainers and also signed by official Debian release people. For example... What is secure about this download link? http://cdimage.debian.org/debian-cd/7.5.0/i386/iso-cd/debian-7.5.0-i386-netinst.iso Sure I can also download and check the signatures from here: http://cdimage.debian.org/debian-cd/7.5.0/i386/iso-cd/ However, what if http://cdimage.debian.org/ is actually an NSA mirror site and not the real one? Lets say that I want download anything from http://cdimage.debian.org/ My downloader resolves http://cdimage.debian.org/ to NSA mirror site through DNS cache poisoning or some other means. So, whatever I am downloading is already compromised. All signatures are valid but are from the NSA. So there is no way for me to actually check that I have downloaded valid files if everything that I see is actually faked! If I go edit apt sources list and manage to get an actual real Debian server update, then apt tells me that all packages available to download are security compromised. Or lets say that I get a real install ISO disc and then later on my apt mirror site is redirected to NSA mirror. Apt will tell me that all packages available to download are security compromised. One of the two scenarios above has actually happened to me!!! I don't know if it is actually the NSA but it DID happen to me. Aptitude was telling me that every single package available for download was compromised! Think about this for a minute. If my ISP or upstream provider is secretly cooperating with the NSA and the NSA wants to compromise my machine, they can make it so that everything that I download is through an NSA source! Remember, the NSA can create VALID SSL certificates for any website on the fly. Your web browser trusts many certificate authorities and which ones are cooperating with the NSA? So how can we really be sure that our Debian install has not been compromised from the beginning? On Thu, Jul 3, 2014 at 8:44 PM, Hans-Christoph Steiner h...@at.or.at wrote: After the latest revelation about NSA tracking all Tor downloads[1] (with source code!) and the whole Debian mirrors and MITM redux, I think we should start talking about concrete steps that we can take to improve
could we maybe serve checksums TLS on some mirrors? (was Re: concrete steps for improving apt downloading security and privacy)
On Thu, Jul 10, 2014 at 9:29 AM, Kitty Cat realizar.la@gmail.com wrote: For years I have been concerned with MITM attacks on Debian mirrors. [...] Hate to trivialize your concerns, but the Debian organization cannot control the mirrors people provide it and remain Debian. You have to remember that when even proposing problems, much less solutions. However, what if http://cdimage.debian.org/ is actually an NSA mirror site and not the real one? [...] When I download a new install image, I pretty much always go to random mirrors, some largish/mainish and some smalish/obscure and download the copies of the checksum files. If all the checksum files compare, I can be pretty confident that one of the following conditions exists: (1) The image is good if the checksum command reports the correct checksum. (2) Some attacker has compromised every mirror I have accessed. (3) Some attacker is doing deep inspections on my traffic and redirecting traffic every time I go looking for a debian mirror. I check a minimum of three mirrors, but when I'm feeling especially paranoid I'll check five or six. It occurs to me that I might cede some usefulness to having the checksums (not images) served TLS transport on at least one of the mirrors, if and only if I remember to set the SSL_CERT_FILE before I fire up lynx to go get the checksums. It won't help me if my randomness in choosing the servers isn't good enough in case (2), but it should help in case (3). -- Joel Rees Computer storage is just fancy paper, and the CPU and I/O are just a fancy pens -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iM+6AYc1owhZty+kR55VaXkOP8zd=y7u4vntv0ceco...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
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? 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 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. 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. Comments? -eirik Ps: please trim and quote appropriately when posting to the list. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d25f241b-aaa2-449e-a98b-d40d8e3d3...@email.android.com
External check
CVE-2013-6495: RESERVED CVE-2014-4740: missing from list -- The output might be a bit terse, but the above ids are known elsewhere, check the references in the tracker. The second part indicates the status of that id in the tracker at the moment the script was run. -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53be3611.zhlk5ticd58wsifb%atomo64+st...@gmail.com
