Re: concrete steps for improving apt downloading security and privacy
Am 19.09.14 um 06:34 schrieb Paul Wise: On Fri, Sep 19, 2014 at 9:30 AM, Hans-Christoph Steiner wrote: Finally did this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153 Please note that you proposal to add signatures to .deb files will break reproducible builds because the hash of the .deb will differ depending on who signed it: https://wiki.debian.org/ReproducibleBuilds I think it would be far better to ship detached signatures in the archive since that allows for reproducible builds and also means there could be more than one signer (say one buildd, one Debian sponsor and one package maintainer). Isn`t there really any way to include the signatures in the header of the .deb files? Why not simply add multiple signature files in the control.tar.gz of a .deb just next to the md5sums which should in deed be a sha256sums (otherwise there is no way to establish a 'chain of trust'). That would not add any non-determinism because if it is done right then we can have all the signers in the package! It would be far better than detaching the signatures from the package because the general use case where you need package signatures is the manual download of packages. Detached signatures are completely useless for such a use case! -- 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/541c005d.2010...@gmail.com
Re: concrete steps for improving apt downloading security and privacy
Holger Levsen wrote: Hi Hans, On Mittwoch, 16. Juli 2014, Hans-Christoph Steiner wrote: What I'm talking about already exists in Debian, but is rarely used. dpkg-sig creates a signature that is embedded in the .deb file. So that means no matter how the .deb file got onto a system, that signature can be verified. I'm proposing to start making dpkg-sig a standard part of official .deb files. This can be done in stages to make it manageable. Here's a rough idea of that: how about you file a bug against dpkg-sig and put your plan and justification in there. Here on the mailinglist it will just be lost... Finally did this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153 And someone else filed a bug to get apt-transport-https included in apt: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756535 .hc signature.asc Description: OpenPGP digital signature
Re: concrete steps for improving apt downloading security and privacy
On Fri, Sep 19, 2014 at 9:30 AM, Hans-Christoph Steiner wrote: Finally did this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153 Please note that you proposal to add signatures to .deb files will break reproducible builds because the hash of the .deb will differ depending on who signed it: https://wiki.debian.org/ReproducibleBuilds I think it would be far better to ship detached signatures in the archive since that allows for reproducible builds and also means there could be more than one signer (say one buildd, one Debian sponsor and one package maintainer). -- bye, pabs https://wiki.debian.org/PaulWise -- 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/CAKTje6EGFXcOpT3K7C2imneW4FPxnypwQfNUMjuLZ3=k1pf...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
Hi Hans, On Mittwoch, 16. Juli 2014, Hans-Christoph Steiner wrote: What I'm talking about already exists in Debian, but is rarely used. dpkg-sig creates a signature that is embedded in the .deb file. So that means no matter how the .deb file got onto a system, that signature can be verified. I'm proposing to start making dpkg-sig a standard part of official .deb files. This can be done in stages to make it manageable. Here's a rough idea of that: how about you file a bug against dpkg-sig and put your plan and justification in there. Here on the mailinglist it will just be lost... cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: concrete steps for improving apt downloading security and privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 16-07-14 18:26, Hans-Christoph Steiner wrote: On 07/16/2014 08:06 AM, Holger Levsen wrote: Hi, On Mittwoch, 16. Juli 2014, Michael Stone wrote: Yes you are--what you described is exactly how the Release files work. Well, there are (many) other .debs on the net which are not part of our releases, so it still seems to me that making .changes files accessable in standardized ways could be very useful. What I'm talking about already exists in Debian, but is rarely used. dpkg-sig creates a signature that is embedded in the .deb file. So that means no matter how the .deb file got onto a system, that signature can be verified. I'm proposing to start making dpkg-sig a standard part of official .deb files. This can be done in stages to make it manageable. Here's a rough idea of that: 1. Adding a 'builder' signature should be easy to start with, make `debsign` also run `dpkg-sig --sign builder` on any .deb files it finds. I believe that `dpkg -i` will already try to verify a signature if it exists. 2. add something like `dpkg --require-debsig` to force checking of the dpkg-sig signature. This would be optional to start with, and complimentary to the already existing `dpkg --no-debsig`. 3. make `dpkg-buildpackage` call `dpkg-sig --sign builder --sign-changes full` to sign packages. 4. etc. As for Michael's complaint that I have not described a real problem, I have tried already in the thread, so I'll try again in bullet points: * TAILS is a Debian-based live CD * the core system image by definition cannot be modified (live CD) * it has a feature for persistent storage of files on a USB thumb drive * it also can save apt cache/lib to that persistent store * it will automatically install packages on boot from that store * mostly people use TAILS in online mode * there is a fully offline mode in development * offline TAILS cannot verify the packages if apt lists are 2 weeks * updating the apt cache/lib is painful on an offline machine * an offline machine's threat model is drastically simpler On top of all that, each update increases risk of compromise on offline machines because each new update provides a vector to run a script or introduce new code that otherwise does not exist (no network!). And any decent attacker with physical access to the machine will always get in. Other people want to be able to directly download .deb packages and have then verified as part of the install process. This is not my primary concern, but I do think it is a valid one. It would also be addressed by fully support of dpkg-sig. I fully agree with Hans-Cristoph here. Looking at other distros, Arch Linux' package manager has had a feature to enable SignedOnly packages for a while now, and I found it extremely useful in my deployments. Their wiki's related page is an interesting start to read about: https://wiki.archlinux.org/index.php/DeveloperWiki:Package_signing As far as I understand for Debian it's more a matter of improving packaging best practices rather than developing/integrating new features. If we have work to be done on both sides, it would be nice to split it now and address the two concerns separately. Kind regards, - -- Giuseppe Mazzotta -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTx5HLAAoJEKWX1kB3NXekY2oH/jBCo4+9c07Y7GNRaM1rkXh6 zr8vYG6tQJDco7Imf2ug1CrSHKUe5nIziwlj0qolq8D0eE33TDfOsztPo5WaqFw6 w5xXwP03cf+pR6VBO+/4fNHV6c/uW29biVcktePvEBFQH5AW8778rM8u0RLNBTol cBnq2t3m5FjSQN4dmRqGrxaViSy9S2qoxThOajr8cmrT/dxRvf2t8aOj2z+REHkb 85DZVNcKXEYft0atkoQO8ihwg51vnVnjxYcUcy+hEEM6UryGJ3awN1tMipCmAisR lExNhqgjOghvbuzYP1B9MBhvDQGeLTjysfFfYELtOgVakAoyzTgV1gMNtVuYnn8= =pnyf -END PGP SIGNATURE- -- 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/53c791cb.4060...@bitonic.nl
Re: concrete steps for improving apt downloading security and privacy
A little context? On Thu, Jul 17, 2014 at 1:26 AM, Hans-Christoph Steiner h...@at.or.at wrote: [...] * TAILS is a Debian-based live CD * the core system image by definition cannot be modified (live CD) * it has a feature for persistent storage of files on a USB thumb drive What happens when you put your live-image CD or USB in a box whose boot ROM or BIOS ROM has been overwritten through some vulnerability and now contains a hook to a backdoor? I'm not going to say that the whole idea of a live-image system is full of holes, but I personally do not trust anything important to any of the live images I use from time to time on hardware I don't control, except for the live CDs I use for repairing systems that have gone belly-up. I have, in the past, brought live USBs home from work and booted them on my home hardware. I don't do that any more. (I'd have to mount the USB on a running system at home and verify the parts of the file system that shouldn't change.) * it also can save apt cache/lib to that persistent store * it will automatically install packages on boot from that store * mostly people use TAILS in online mode * there is a fully offline mode in development * offline TAILS cannot verify the packages if apt lists are 2 weeks Yes it can. * updating the apt cache/lib is painful on an offline machine Don't turn your nose up at wrappers. Lots of very useful stuff around that is just wrapping something else. Quite stable, if the wrapper does its job fully. * an offline machine's threat model is drastically simpler I disagree with that, as you see. On top of all that, each update increases risk of compromise on offline machines because each new update provides a vector to run a script or introduce new code that otherwise does not exist (no network!). I suggest looking at the reasons for that again. And any decent attacker with physical access to the machine will always get in. Isn't this a red herring? Other people want to be able to directly download .deb packages and have then verified as part of the install process. This is not my primary concern, but I do think it is a valid one. It would also be addressed by fully support of dpkg-sig. .hc I understand the hesitation. Having individual packages signed is a good lead to a false sense of security. One point I strongly suggest considering is, for example, that firefox, direct from mozilla.org, on stock debian, is more likely to have vulnerabilities than firefox (iceweasel) loaded from the debian packages archives. -- Joel Rees Computer memory is just fancy paper. The CPU and IO devices are just 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/caar43im5bnalp1fny9j63cqezizpf0uxgm-txufasc-lj6m...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On 07/17/2014 08:20 AM, Joel Rees wrote: A little context? On Thu, Jul 17, 2014 at 1:26 AM, Hans-Christoph Steiner h...@at.or.at wrote: [...] * TAILS is a Debian-based live CD * the core system image by definition cannot be modified (live CD) * it has a feature for persistent storage of files on a USB thumb drive What happens when you put your live-image CD or USB in a box whose boot ROM or BIOS ROM has been overwritten through some vulnerability and now contains a hook to a backdoor? I'm not going to say that the whole idea of a live-image system is full of holes, but I personally do not trust anything important to any of the live images I use from time to time on hardware I don't control, except for the live CDs I use for repairing systems that have gone belly-up. I have, in the past, brought live USBs home from work and booted them on my home hardware. I don't do that any more. (I'd have to mount the USB on a running system at home and verify the parts of the file system that shouldn't change.) _All_ software installed is vulnerable to this kind of exploit. Using a live CD does not address the issue of an untrusted BIOS any more than using a normal Debian install. The live CD does address lots of other issues that cannot be addressed easily in a normal Debian install. Same goes with offline vs online systems, both are entirely vulnerable to already exploited BIOSes. An offline machine reduces the risk since an exploited BIOS could only be installed by gaining physical access. * it also can save apt cache/lib to that persistent store * it will automatically install packages on boot from that store * mostly people use TAILS in online mode * there is a fully offline mode in development * offline TAILS cannot verify the packages if apt lists are 2 weeks Yes it can. Not without modifying the apt config. The point here is to have a working system that is tested and audited, rather than just a set of instructions or recommendations. .hc * updating the apt cache/lib is painful on an offline machine Don't turn your nose up at wrappers. Lots of very useful stuff around that is just wrapping something else. Quite stable, if the wrapper does its job fully. * an offline machine's threat model is drastically simpler I disagree with that, as you see. On top of all that, each update increases risk of compromise on offline machines because each new update provides a vector to run a script or introduce new code that otherwise does not exist (no network!). I suggest looking at the reasons for that again. And any decent attacker with physical access to the machine will always get in. Isn't this a red herring? Other people want to be able to directly download .deb packages and have then verified as part of the install process. This is not my primary concern, but I do think it is a valid one. It would also be addressed by fully support of dpkg-sig. .hc I understand the hesitation. Having individual packages signed is a good lead to a false sense of security. One point I strongly suggest considering is, for example, that firefox, direct from mozilla.org, on stock debian, is more likely to have vulnerabilities than firefox (iceweasel) loaded from the debian packages archives. -- 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/53c7ffee.6060...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On Thu, Jul 17, 2014 at 12:55:10PM -0400, Hans-Christoph Steiner wrote: Not without modifying the apt config. The point here is to have a working system that is tested and audited, rather than just a set of instructions or recommendations. That would be why you'd create a wrapper to faciliate the config changes necessary for your particular situation. 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/4bea5e4e-0dd9-11e4-b619-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 16, 2014 at 01:45:36AM +0200, Holger Levsen wrote: AIUI Hans-Christoph wants something else _also_, not instead. And technically I think those signed .debs even exist already, via hashes in signed .changes files. Or am I getting something wrong? Yes you are--what you described is exactly how the Release files work. 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/2d6a9800-0cd3-11e4-a8ca-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
Hi, On Mittwoch, 16. Juli 2014, Michael Stone wrote: Yes you are--what you described is exactly how the Release files work. Well, there are (many) other .debs on the net which are not part of our releases, so it still seems to me that making .changes files accessable in standardized ways could be very useful. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: concrete steps for improving apt downloading security and privacy
On 07/16/2014 08:06 AM, Holger Levsen wrote: Hi, On Mittwoch, 16. Juli 2014, Michael Stone wrote: Yes you are--what you described is exactly how the Release files work. Well, there are (many) other .debs on the net which are not part of our releases, so it still seems to me that making .changes files accessable in standardized ways could be very useful. What I'm talking about already exists in Debian, but is rarely used. dpkg-sig creates a signature that is embedded in the .deb file. So that means no matter how the .deb file got onto a system, that signature can be verified. I'm proposing to start making dpkg-sig a standard part of official .deb files. This can be done in stages to make it manageable. Here's a rough idea of that: 1. Adding a 'builder' signature should be easy to start with, make `debsign` also run `dpkg-sig --sign builder` on any .deb files it finds. I believe that `dpkg -i` will already try to verify a signature if it exists. 2. add something like `dpkg --require-debsig` to force checking of the dpkg-sig signature. This would be optional to start with, and complimentary to the already existing `dpkg --no-debsig`. 3. make `dpkg-buildpackage` call `dpkg-sig --sign builder --sign-changes full` to sign packages. 4. etc. As for Michael's complaint that I have not described a real problem, I have tried already in the thread, so I'll try again in bullet points: * TAILS is a Debian-based live CD * the core system image by definition cannot be modified (live CD) * it has a feature for persistent storage of files on a USB thumb drive * it also can save apt cache/lib to that persistent store * it will automatically install packages on boot from that store * mostly people use TAILS in online mode * there is a fully offline mode in development * offline TAILS cannot verify the packages if apt lists are 2 weeks * updating the apt cache/lib is painful on an offline machine * an offline machine's threat model is drastically simpler On top of all that, each update increases risk of compromise on offline machines because each new update provides a vector to run a script or introduce new code that otherwise does not exist (no network!). And any decent attacker with physical access to the machine will always get in. Other people want to be able to directly download .deb packages and have then verified as part of the install process. This is not my primary concern, but I do think it is a valid one. It would also be addressed by fully support of dpkg-sig. .hc signature.asc Description: OpenPGP digital signature
Re: concrete steps for improving apt downloading security and privacy
On 07/14/2014 01:57 PM, Michael Stone wrote: On Mon, Jul 14, 2014 at 01:22:10PM -0400, Hans-Christoph Steiner wrote: Or, you could make use of the Check-Valid-Until and Min-ValidTime options in apt.conf. There's a reason things are done the way they are, and you probably aren't going to find a lot of interest in getting people to do a lot of work to create a system which is duplicative at best and less secure at worst. Sure, those options would work well for people who understand them and want to tweak them. I'm not interested in that. I'm currently working on a TAILS-based system for running build and signing processes on machines that _never_ go online. So that means that changing the apt config is not an option. I'm working with apt-offline currently and that helps a lot. You're making an assertion and not supporting it. Changing a configuration parameter is unacceptable, but switching to an entirely different package trust model is ok? You care very much about the trust path to debian packages but not anything else (like the software that's installing them?) Seems like a weird problem, but maybe you're just not fully explaining it. If that's really the constraint set I guess it may be a case of you created your problem, so you get to fix it. TAILS is a live CD, but provides a method of installing and maintaining new packages on top of what is provided by the live CD. That means those packages are stored in an encrypted stash, and are installed on each boot. So in order to use this feature, the apt cache needs to be refreshed using apt-offline at least every two weeks, otherwise the packages won't be installed since apt can no longer validate them. Have you actually tried setting Acquire::Check-Valid-Until off; in apt.conf? What was the result? How do you propose managing a distro that mostly needs apt as is, but other times need Acquire::Check-Valid-Until off;? In other words, how would you manage a distro that sometimes uses apt as it was designed, and other times has to tweak in ways that would break the main use case? That sounds like a recipe for lots of edge cases and bad bugs. The situation in TAILS in not like normal Debian installed, but it basically the same for any live CD that has the option of installing additional packages from a persistent store. TAILS is mostly meant to be on online system, but fully offline support is in the works. Having signatures in .debs is entirely complementary to the existing apt system. It does not change how apt works at all in the normal network mode. The apt metadata would be used to verify that repo information is up-to-date, downloaded packages are intact, etc. Then the moment of install would use the signature in the .deb to verify that the .deb is intact and signed by a trusted key. Right now, `dpkg -i package.deb` does not verify against any signature. So for the offline system, if the .deb files have signatures, the .deb files can be copied on the offline machine however (apt-offline is a good option, but others are possible), then they can be installed, uninstalled, etc. after verifying that the signature in the .deb is trusted. So really, this would not be modifying apt so much as modifying `dpkg -i`. .hc -- 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/53c564a8.4000...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote: How do you propose managing a distro that mostly needs apt as is, but other times need Acquire::Check-Valid-Until off;? In other words, how would you manage a distro that sometimes uses apt as it was designed, and other times has to tweak in ways that would break the main use case? That sounds like a recipe for lots of edge cases and bad bugs. Um, so does your suggested change. Using apt with the valid check off is fundamentally equivalent to using signed .debs. Both mechanisms have the same failure modes, but one is a configuration change and one reworks the trust path to get to the same place. is up-to-date, downloaded packages are intact, etc. Then the moment of install would use the signature in the .deb to verify that the .deb is intact and signed by a trusted key. Right now, `dpkg -i package.deb` does not verify against any signature. This is funcationally the same thing as checking that the hash of the deb is the same as the one listed in the Releases file (or apt-cache show) before installing the deb. You could do that in a wrapper. So for the offline system, if the .deb files have signatures, the .deb files can be copied on the offline machine however (apt-offline is a good option, but others are possible), then they can be installed, uninstalled, etc. after verifying that the signature in the .deb is trusted. So really, this would not be modifying apt so much as modifying `dpkg -i`. Right, as I said, a complete reworking of the trust path (new code, new bugs, etc.) to get essentially the same result. It sounds like what you need to do to get the result you're talking about is grab the releases file along with the deb, validate the sig on the releases file (except ignoring the expiration), verify the hash of the .deb, then install the .deb. Depending on the specifics of the implementation you could do that from an apt command line by setting the Check-Valid-Until via -o or by writing a dpkg wrapper. In any event it shouldn't be all that much code and certainly much less what you're proposing. (I'd also hope that your front end would at least tell the user how old the Release file is, and that the distributor recommends checking for a newer version. The expiration mechanism is important to ensure that people aren't installing old/vulnerable versions of trusted packages--which may be equivalent to installing trojan packages.) 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/6e73f5b0-0c49-11e4-ac7f-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On 07/15/2014 02:11 PM, Michael Stone wrote: On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote: How do you propose managing a distro that mostly needs apt as is, but other times need Acquire::Check-Valid-Until off;? In other words, how would you manage a distro that sometimes uses apt as it was designed, and other times has to tweak in ways that would break the main use case? That sounds like a recipe for lots of edge cases and bad bugs. Um, so does your suggested change. Using apt with the valid check off is fundamentally equivalent to using signed .debs. Both mechanisms have the same failure modes, but one is a configuration change and one reworks the trust path to get to the same place. is up-to-date, downloaded packages are intact, etc. Then the moment of install would use the signature in the .deb to verify that the .deb is intact and signed by a trusted key. Right now, `dpkg -i package.deb` does not verify against any signature. This is funcationally the same thing as checking that the hash of the deb is the same as the one listed in the Releases file (or apt-cache show) before installing the deb. You could do that in a wrapper. So for the offline system, if the .deb files have signatures, the .deb files can be copied on the offline machine however (apt-offline is a good option, but others are possible), then they can be installed, uninstalled, etc. after verifying that the signature in the .deb is trusted. So really, this would not be modifying apt so much as modifying `dpkg -i`. Right, as I said, a complete reworking of the trust path (new code, new bugs, etc.) to get essentially the same result. It sounds like what you need to do to get the result you're talking about is grab the releases file along with the deb, validate the sig on the releases file (except ignoring the expiration), verify the hash of the .deb, then install the .deb. Depending on the specifics of the implementation you could do that from an apt command line by setting the Check-Valid-Until via -o or by writing a dpkg wrapper. In any event it shouldn't be all that much code and certainly much less what you're proposing. (I'd also hope that your front end would at least tell the user how old the Release file is, and that the distributor recommends checking for a newer version. The expiration mechanism is important to ensure that people aren't installing old/vulnerable versions of trusted packages--which may be equivalent to installing trojan packages.) Mike Stone There is already an existing format for signing and verifying .debs, the signing keys infrastructure is already in place, there is a clear spot to validate on install, doing some hacked together dpkg wrapper sounds like a good way to prototype, but a bad way to widely deploy a working system. I'm not saying that adding .deb signature validation to `dpkg -i` would be trivial and without risk. But the idea of validating signed package files on install is hardly revolutionary or even novel any more. Indeed it is pretty widespread: think Android, Fedora, Java, iOS, etc. I think it is the cleanest approach for the problem that I've outlined. .hc -- 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/53c58e06.3030...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On Tue, Jul 15, 2014 at 04:24:38PM -0400, Hans-Christoph Steiner wrote: I'm not saying that adding .deb signature validation to `dpkg -i` would be trivial and without risk. But the idea of validating signed package files on install is hardly revolutionary or even novel any more. Indeed it is pretty widespread: think Android, Fedora, Java, iOS, etc. I think it is the cleanest approach for the problem that I've outlined. Except that you haven't addressed *at all* why the current mechanism is insufficient, except that you don't like it and want to do something else instead. You understand why that argument isn't particularly compelling. 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/934303a6-0c60-11e4-b95c-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
Hi, On Dienstag, 15. Juli 2014, Michael Stone wrote: Except that you haven't addressed *at all* why the current mechanism is insufficient, except that you don't like it and want to do something else instead. AIUI Hans-Christoph wants something else _also_, not instead. And technically I think those signed .debs even exist already, via hashes in signed .changes files. Or am I getting something wrong? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: concrete steps for improving apt downloading security and privacy
I agree that .deb packages should be individually signed, but I don't think that the current apt system is vulnerable to package corruption. Having a signature in the .deb. would make things a lot more flexible in terms of distribution because a .deb could be verified no matter how it ends up on your system. That lets people experiment and create their own distribution systems, or use the tools that they already know when apt does not work for them (internet outages, blocks, etc). Having individually signed .deb packages would not change the existing workflow since uploaders already have to sign packages before uploading them to Debian. This has been discussed in the past. I really think it is just a matter of someone doing the work. .hc On 07/09/2014 08:29 PM, Kitty Cat wrote: 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/ http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/ My downloader resolves http://cdimage.debian.org/ http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/ 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 the situation. The first things that came to mind would be quite easy to do: * include apt-transport-https by default in Debian * include existing HTTPS mirrors wherever Debian mirrors are listed * https://www.debian.org/mirror/list * netselect-apt * http://http.debian.net/ * apt-get's mirror:// * make http://cdn.debian.net/ have an only-HTTPS version * encourage mirror operators to set up a Tor Hidden Service There is already a good collection of HTTPS mirrors to choose from (not-counting all the ones that have HTTPS enabled without a proper certificate). https://mirror.i3d.net/pub/debian/ https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/ https://mirror.cse.unsw.edu.au/debian/ https://mirrors.kernel.org/debian/ https://the.earth.li/debian/ https://mirror.vorboss.net/debian/ https://ftp.arnes.si/pub/packages/debian/ https://ftp.iitm.ac.in/debian/ https://ftp.uni-erlangen.de/debian/ https://ftp-stud.hs-esslingen.de/debian/ https://mirrors.ustc.edu.cn/debian/ https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/ https://dennou-q.gfd-dennou.org/debian/ https://dennou-k.gfd-dennou.org/debian/ https://dennou-h.gfd-dennou.org/debian/ .hc [1] http://daserste.ndr.de/panorama/aktuell/nsa230_page-1.html -- 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/53b6150a.3000...@at.or.at -- To UNSUBSCRIBE, email
Re: concrete steps for improving apt downloading security and privacy
On Tue, Jul 15, 2014 at 12:24 AM, Hans-Christoph Steiner wrote: I agree that .deb packages should be individually signed ... This has been discussed in the past. I really think it is just a matter of someone doing the work. The work has been done many years ago and has been in the archive for ages but has probably bitrotten since apt repo signing won (mostly, some derivatives don't sign their repos) and now no-one uses deb signing (probably). The packages are dpkg-sig debsigs debsig-verify. -- bye, pabs https://wiki.debian.org/PaulWise -- 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/CAKTje6Fk+8zDHmQRsqYLDe0ABAb8q2OMrnRmvyhp2OyYFe=w...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On 07/14/2014 12:31 PM, Paul Wise wrote: On Tue, Jul 15, 2014 at 12:24 AM, Hans-Christoph Steiner wrote: I agree that .deb packages should be individually signed ... This has been discussed in the past. I really think it is just a matter of someone doing the work. The work has been done many years ago and has been in the archive for ages but has probably bitrotten since apt repo signing won (mostly, some derivatives don't sign their repos) and now no-one uses deb signing (probably). The packages are dpkg-sig debsigs debsig-verify. Ah yes, I had forgotten about those. What I'd like to see is that stuff being integrated into the existing Debian packaging process, so that when you sign an upload, the .deb is automatically signed as well. One place that this will help a lot is managing completely offline machines, like machines for running secure build and signing processes. Right now, in order to install a package securely on an offline machine, I have to make sure that the apt-get cache is no older than two weeks, otherwise apt-get considers the info expired and no longer trusted. It make sense to have a listing of packages and updates expire. It does not make sense to have the signature on an individual package expire. Debian does not provide the later option. I'd like to contribute to this effort, so the first question are what are any issues that might block including this into normal package signing process when someone is uploading to Debian? That seems like the easiest and lowest risk place to start. .hc -- 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/53c40932.4070...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On Tue, Jul 15, 2014 at 12:45 AM, Hans-Christoph Steiner wrote: I'd like to contribute to this effort First thing is to get #733029 fixed, which involves disabling signing by default (signing should be done after testing not before) and adding a signing tool to dpkg-dev. Then debsign/debuild need adapting to the new default and the new signing tool. Then you can modify the dpkg signing tool to sign .deb files using code from the old stuff and convince the dpkg maintainers to accept it. Somewhere in there the old approaches/code should be looked at, checked if they still work and the old documentation and external websites (some of them only on archive.org) and mailing list discussions. -- bye, pabs https://wiki.debian.org/PaulWise -- 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/caktje6gmcuzzrmcqqealto-sj4ybw42t3fkjxxbxbxc282u...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Mon, Jul 14, 2014 at 12:45:38PM -0400, Hans-Christoph Steiner wrote: One place that this will help a lot is managing completely offline machines, like machines for running secure build and signing processes. Right now, in order to install a package securely on an offline machine, I have to make sure that the apt-get cache is no older than two weeks, otherwise apt-get considers the info expired and no longer trusted. It make sense to have a listing of packages and updates expire. It does not make sense to have the signature on an individual package expire. Debian does not provide the later option. Or, you could make use of the Check-Valid-Until and Min-ValidTime options in apt.conf. There's a reason things are done the way they are, and you probably aren't going to find a lot of interest in getting people to do a lot of work to create a system which is duplicative at best and less secure at worst. 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/b0a0301e-0b79-11e4-8363-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On 07/14/2014 12:59 PM, Paul Wise wrote: On Tue, Jul 15, 2014 at 12:45 AM, Hans-Christoph Steiner wrote: I'd like to contribute to this effort First thing is to get #733029 fixed, which involves disabling signing by default (signing should be done after testing not before) and adding a signing tool to dpkg-dev. Then debsign/debuild need adapting to the new default and the new signing tool. Then you can modify the dpkg signing tool to sign .deb files using code from the old stuff and convince the dpkg maintainers to accept it. Somewhere in there the old approaches/code should be looked at, checked if they still work and the old documentation and external websites (some of them only on archive.org) and mailing list discussions. I agree that dpkg-buildpackage should not sign try to sign by default unless the signer in debian/changelog matches the currently logged in person. But there should always be at least builder signature on every .deb. That signature is not there to testify that it is a tested release, it is there to verify that the package was not modified since the builder created it. The Android security model is a good example: you cannot even install an .apk (like an Android .deb) that does not have a signature in it. All .apks must have a valid signature in order to be installed. For debug builds, the Android build tools make it dead simple to use a debug key to sign .apks. .hc -- 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/53c40fcc.7050...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On 07/14/2014 01:12 PM, Michael Stone wrote: On Mon, Jul 14, 2014 at 12:45:38PM -0400, Hans-Christoph Steiner wrote: One place that this will help a lot is managing completely offline machines, like machines for running secure build and signing processes. Right now, in order to install a package securely on an offline machine, I have to make sure that the apt-get cache is no older than two weeks, otherwise apt-get considers the info expired and no longer trusted. It make sense to have a listing of packages and updates expire. It does not make sense to have the signature on an individual package expire. Debian does not provide the later option. Or, you could make use of the Check-Valid-Until and Min-ValidTime options in apt.conf. There's a reason things are done the way they are, and you probably aren't going to find a lot of interest in getting people to do a lot of work to create a system which is duplicative at best and less secure at worst. Mike Stone Sure, those options would work well for people who understand them and want to tweak them. I'm not interested in that. I'm currently working on a TAILS-based system for running build and signing processes on machines that _never_ go online. So that means that changing the apt config is not an option. I'm working with apt-offline currently and that helps a lot. TAILS is a live CD, but provides a method of installing and maintaining new packages on top of what is provided by the live CD. That means those packages are stored in an encrypted stash, and are installed on each boot. So in order to use this feature, the apt cache needs to be refreshed using apt-offline at least every two weeks, otherwise the packages won't be installed since apt can no longer validate them. Having a system that verifies existing .deb files against their own signature would eliminate this problem entirely. The apt expiration is only meant to protect against network attacks, so having to work around the expiration on a completely offline machine only complicates the process of running an offline machine, which also has security ramifications. For more info: https://dev.guardianproject.info/projects/psst/wiki/CleanRoom https://tails.boum.org/doc/first_steps/persistence/configure/index.en.html https://tails.boum.org/blueprint/remember_installed_packages/ https://labs.riseup.net/code/issues/7208 .hc -- 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/53c411c2.4070...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On Mon, Jul 14, 2014 at 01:22:10PM -0400, Hans-Christoph Steiner wrote: Or, you could make use of the Check-Valid-Until and Min-ValidTime options in apt.conf. There's a reason things are done the way they are, and you probably aren't going to find a lot of interest in getting people to do a lot of work to create a system which is duplicative at best and less secure at worst. Sure, those options would work well for people who understand them and want to tweak them. I'm not interested in that. I'm currently working on a TAILS-based system for running build and signing processes on machines that _never_ go online. So that means that changing the apt config is not an option. I'm working with apt-offline currently and that helps a lot. You're making an assertion and not supporting it. Changing a configuration parameter is unacceptable, but switching to an entirely different package trust model is ok? You care very much about the trust path to debian packages but not anything else (like the software that's installing them?) Seems like a weird problem, but maybe you're just not fully explaining it. If that's really the constraint set I guess it may be a case of you created your problem, so you get to fix it. TAILS is a live CD, but provides a method of installing and maintaining new packages on top of what is provided by the live CD. That means those packages are stored in an encrypted stash, and are installed on each boot. So in order to use this feature, the apt cache needs to be refreshed using apt-offline at least every two weeks, otherwise the packages won't be installed since apt can no longer validate them. Have you actually tried setting Acquire::Check-Valid-Until off; in apt.conf? What was the result? 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/d4a2c78e-0b7d-11e4-b7fa-00163eeb5...@msgid.mathom.us
Re: could we maybe serve checksums TLS on some mirrors? (was Re: concrete steps for improving apt downloading security and privacy)
Yes, I also think it is a pretty shame that we can not download the sha256/512sums from a sever secured by https + DNSSEC/DANE. At least the master mirror cdimage.debian.org needs to provide a secure connection for downloading checksums and the *.jigdo and *.template files. Moreover I would appreciate the jigdo program to work with https + evtl. dnssec as well because http is inherently untrusted and thus insecure. Finally jigdo itself would need to be uploaded to the master mirror as we should not execute any program without inspection from a source which is not secured (would imply that the source is also trusted). If we have https + DNSSEC for lists.debian.org and debian.org why not also for cdimage.debian.org? Elmar Am 10.07.2014 um 18:52 schrieb Joel Rees: 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).
Re: concrete steps for improving apt downloading security and privacy
On Sun, Jul 13, 2014 at 1:28 PM, Noah Meyerhans no...@debian.org wrote: On Sun, Jul 13, 2014 at 08:35:56AM +0900, Joel Rees wrote: MD5 has been broken for a small number of applications. Its status is questionable for the rest, but if we want to help break it completely, let's get all the distros that insist on still using MD5 to use it, not just for signing, but for encrypting their distribution images. The point that you miss is that a chosen plaintext attack is not dependent on the secret key in use. If I stand on my head does that make more sense? Nope. Doesn't. It's an attack against the algorithm itself. Looking at it sideways doesn't help, either. If we sign publically available data (be it Debian packages, CD images, or this email) with a given key, we really aren't giving our adversaries anything that they can't create for themselves. Sure we are. We are providing them instances of a different experiment set than any they are likely do generate themselves. Unless we use keys generated by some algorithm they might use to generate data. And we are also giving them the use of our servers. Keys are cheap to generate. Keys that are cheap to generate should not be used on live data. If an adversary wants to perform chosen plaintext analysis, they can do so today with their own keys and with all the common public datasets they want. And generating/managing their own data is a time cost. Moreover, if they fail to use some arbitrary algorithm, their choice of key is hit-and-miss, mostly miss. But if they use some algorithm, they are subject to the problems of brute-forcing against a large attack domain. Getting all the distros that insist on still using MD5 to use it, not just for signing, but for encrypting their distribution images won't change anything. So, when you want to do a survey of most popular TV shows, you just generate your own survey results and don't bother to define and canvas an audience? You do understand that the most effective attacks against the algorithms are statistical in nature? (Not to mention that it shows a fundamental misunderstanding of what a digest algorithm like md5 actually is.) You like to work backwards, trying to generate data from a hash, I suppose? noah -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/caar43iobz5utdg2zdaglm6yszkhnjeo+1fw-whjzpp5smj2...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Mon, Jul 07, 2014 at 08:09:14PM +0900, Joel Rees wrote: But again, that's only half the story. When you send a kernel image encrypted, they have the plaintext and the crypt, and the thing is large and hard. This is the kind of data that can be used to completely break an entire encryption algorithm. When you say break an entire encryption algorithm, do you mean find the key or really break the whole algorithm? If you mean break the whole algorithm and gain the ability to convert ciphertexts to plaintexts no matter what key was used, please consider that they could just encrypt a lot of data with random keys themselves instead of collecting it from the internet. If you mean find the key: So what? You're talking about session keys used in the TLS connection, right? Even if there was the kind of attack you're thinking about, it would only allow an attacker to gain access to the connection that he would be able to MITM anyway without the TLS layer. signature.asc Description: Digital signature
Re: concrete steps for improving apt downloading security and privacy
On Sun, Jul 13, 2014 at 5:04 AM, Jann Horn j...@thejh.net wrote: On Mon, Jul 07, 2014 at 08:09:14PM +0900, Joel Rees wrote: But again, that's only half the story. When you send a kernel image encrypted, they have the plaintext and the crypt, and the thing is large and hard. This is the kind of data that can be used to completely break an entire encryption algorithm. When you say break an entire encryption algorithm, do you mean find the key or really break the whole algorithm? Both, of course. If you mean break the whole algorithm and gain the ability to convert ciphertexts to plaintexts no matter what key was used, please consider that they could just encrypt a lot of data with random keys themselves instead of collecting it from the internet. If you mean find the key: So what? You're talking about session keys used in the TLS connection, right? Even if there was the kind of attack you're thinking about, it would only allow an attacker to gain access to the connection that he would be able to MITM anyway without the TLS layer. What are the encryption methods that underlie the current implementations of TLS? What were the previous methods? Why did they have to be changed? What did the research that induced the change use in getting the results they got? Have the researchers given up? No? What kinds of data do they use? Note that we still don't have a publicly known general attack against MD5 encryption for arbitrary plaintexts. MD5 has been broken for a small number of applications. Its status is questionable for the rest, but if we want to help break it completely, let's get all the distros that insist on still using MD5 to use it, not just for signing, but for encrypting their distribution images. I'm not talking about suddenly facing the end of the world as we know it tomorrow. I'm talking about choosing to push the time when we have to shift encryption methods again a few years forward by casually providing more data for research. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/CAAr43iN=fguxegEdr16jr37tuE8osHDDPRdHZicDfZU=dyp...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Sun, Jul 13, 2014 at 08:35:56AM +0900, Joel Rees wrote: MD5 has been broken for a small number of applications. Its status is questionable for the rest, but if we want to help break it completely, let's get all the distros that insist on still using MD5 to use it, not just for signing, but for encrypting their distribution images. The point that you miss is that a chosen plaintext attack is not dependent on the secret key in use. It's an attack against the algorithm itself. If we sign publically available data (be it Debian packages, CD images, or this email) with a given key, we really aren't giving our adversaries anything that they can't create for themselves. Keys are cheap to generate. If an adversary wants to perform chosen plaintext analysis, they can do so today with their own keys and with all the common public datasets they want. Getting all the distros that insist on still using MD5 to use it, not just for signing, but for encrypting their distribution images won't change anything. (Not to mention that it shows a fundamental misunderstanding of what a digest algorithm like md5 actually is.) noah signature.asc Description: Digital signature
Re: concrete steps for improving apt downloading security and privacy
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
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
Re: concrete steps for improving apt downloading security and privacy
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/ http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/ My downloader resolves http://cdimage.debian.org/ http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/ 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 the situation. The first things that came to mind would be quite easy to do: * include apt-transport-https by default in Debian * include existing HTTPS mirrors wherever Debian mirrors are listed * https://www.debian.org/mirror/list * netselect-apt * http://http.debian.net/ * apt-get's mirror:// * make http://cdn.debian.net/ have an only-HTTPS version * encourage mirror operators to set up a Tor Hidden Service There is already a good collection of HTTPS mirrors to choose from (not-counting all the ones that have HTTPS enabled without a proper certificate). https://mirror.i3d.net/pub/debian/ https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/ https://mirror.cse.unsw.edu.au/debian/ https://mirrors.kernel.org/debian/ https://the.earth.li/debian/ https://mirror.vorboss.net/debian/ https://ftp.arnes.si/pub/packages/debian/ https://ftp.iitm.ac.in/debian/ https://ftp.uni-erlangen.de/debian/ https://ftp-stud.hs-esslingen.de/debian/ https://mirrors.ustc.edu.cn/debian/ https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/ https://dennou-q.gfd-dennou.org/debian/ https://dennou-k.gfd-dennou.org/debian/ https://dennou-h.gfd-dennou.org/debian/ .hc [1] http://daserste.ndr.de/panorama/aktuell/nsa230_page-1.html -- 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/53b6150a.3000...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 9, 2014 at 10: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? It would be nice for this information to be somewhere more formal than in mailing list archives. Threat models are becoming increasingly important to convey to end users. -- Darius Jahandarie -- 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/cafanwtwqzfcvnb9ozm1wmccmzytvpjbtot4om9w+bf9anpc...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
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
On Wed, Jul 09, 2014 at 10:15:59PM -0400, Darius Jahandarie wrote: It would be nice for this information to be somewhere more formal than in mailing list archives. Threat models are becoming increasingly important to convey to end users. The mailing list discussion referenced the sources... -- 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/44b71312-07dd-11e4-8a0a-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 9, 2014 at 10:53 PM, Michael Stone mst...@debian.org wrote: On Wed, Jul 09, 2014 at 10:15:59PM -0400, Darius Jahandarie wrote: It would be nice for this information to be somewhere more formal than in mailing list archives. Threat models are becoming increasingly important to convey to end users. The mailing list discussion referenced the sources... What I mean by more formal can be approximated by discoverable by searching 'debian security' on Google and clicking on the first link. If Tux Q. Debiannewbie doesn't know what adversaries with what powers they are/aren't protected against for their use cases without looking hard and being a security expert, it's hard to make serious claims that Debian is actually protecting its users. (Halting the endless discussion loops on debian-security@ is just a nice side effect of fixing the actual problem.) -- Darius Jahandarie -- 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/cafanwtvwpq8qxoj+yyn_nhpxymq4hoazn58oo5etcquzoke...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 09, 2014 at 11:11:44PM -0400, Darius Jahandarie wrote: If Tux Q. Debiannewbie doesn't know what adversaries with what powers they are/aren't protected against for their use cases without looking hard and being a security expert, it's hard to make serious claims that Debian is actually protecting its users. I frankly find it hard to believe that someone who is unwilling to click past the first link when researching actually cares much about any kind of writeup of threat models. I'll make it simple: if you're completely unsophisticated and worried about a government hijacking your linux distribution to spy on you, there's nothing debian can do to help you. If you're low profile and uninteresting, the government doesn't care about you. If you're actually being targeted by well funded and sophisticated adversaries, they're going to get you unless you put a heck of a lot more effort in than clicking on the first link. 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/efdda2b2-07e0-11e4-bd13-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
On Wed, Jul 9, 2014 at 11:23 PM, Michael Stone mst...@debian.org wrote: I frankly find it hard to believe that someone who is unwilling to click past the first link when researching actually cares much about any kind of writeup of threat models. I'll make it simple: if you're completely unsophisticated and worried about a government hijacking your linux distribution to spy on you, there's nothing debian can do to help you. If you're low profile and uninteresting, the government doesn't care about you. If you're actually being targeted by well funded and sophisticated adversaries, they're going to get you unless you put a heck of a lot more effort in than clicking on the first link. 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. -- Darius Jahandarie -- 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/CAFANWtVc1URqiCiOBYBpxEDUyWh8Qn0sf_=esqt3x9bu3u_...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
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
I don't understand why so much noise on this subject. Https for Debian mirrors and a server centralized, maintained and owned by Debian for debsig-verify / debsums packages it will be enough, at least for the next years. PS: from now on I will filter out any email regarding nsa, debian mirrors or mitm... :) Best regards, Elias On 07/08/2014 01:43 AM, Jeremie Marguerie wrote: On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT hims...@louruppert.com wrote: If I'm looking at a catalog page from a shoe store on my table, connected via the phone network, getting close to my 2G cap for my wireless router for the month. My battery's getting low. Do I want to waste bandwidth and CPU cycles for TLS encoding, just for pictures of shoes? Let's try to turn our focus back to the question at hand, which is whether there are merits to promoting https mirrors for users who have concerns about being watchlisted based on their software choices. I think client cpu cycle and bandwidth concerns are a bit of an anachronism these days anyway. I think you pulled out the only reason why using https for mirrors would be useful. The threat analysis doesn't show any practicable way for the any attacker to prevent alter packages even with control of the network. He could block updates but the client-side would noticed: out-of-date repository and package list, failed to download specific packages. HTTPS is a solution to this risk scenario: A) I don't want anyone to know which package I download (passive listening) B) I don't want a third party to selectively prevent me from downloading a package/update (active man i the middle) Scenario A is more likely to happen or to already be in place. HTTPS in this case is *not* about security but just privacy. 1) Performance concern: The CPU cycles for encrypting is now low enough so that it seems feasible. Not all package providers need to provide https-based repository but having a few of those and give them visibility would be greatly appreciated. 2) TLS certificates: we do not need the package to be behind a debian certificate, just to be behind a certificate trusted by a recognized third party (same requirement as for websites). Since we do not seek authentication of the package but just privacy, we only need to ensure that we talk to the server we wanted to, whichever it is. -- 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/53bb9ab5.6070...@skin.ro
the calculus of encrypting non-textual data (was Re: concrete steps for improving apt downloading security and privacy)
On Tue, Jul 8, 2014 at 5:13 AM, Andrea Zwirner and...@linkspirit.org wrote: On 07/07/2014 13:09, Joel Rees wrote: Sorry Joel, I almost totally disagree with your vision on privacy and security, but I really i don't want to go into the merit of it, because I think Lou is representing my vision already; I only have a question: Did you know that encrypting a picture sometimes results in a picture that looks like it has been through a random color-permuting filter? Can you proof it? Memory of coursework in encryption. The professor did some simple encryption on uncompressed images and showed how the results tended not to hide the things one would want hidden. Then he pointed out that the parts of an image with the most information are the parts that are least likely to compress. And he pointed out that standard encryption methods tend to be byte-oriented, for speed. He did not require us to do any homework on it, so I don't have any special tools in my notebooks. 30 years ago. Heh. The technology has changed somewhat since then, but I recently read about some standard encrypted sound files that were playable, noisy, but recognizable. Same principle. 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? You'll note that I never said it could be done on every encrypted image. I assume that, now the math has been pointed out to you, you won't mind if I decline the challenge? 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). :-) Give them my regards, and I hope they are not disappointed. I've got other things to do. Andrea Zwirner Sent from my Sylpheed -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/caar43im8zdukxqmnej8_oqcjhreto0p_qtdhyiq5wilpzye...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On 07/07/2014 06:43 PM, Jeremie Marguerie wrote: On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT hims...@louruppert.com wrote: If I'm looking at a catalog page from a shoe store on my table, connected via the phone network, getting close to my 2G cap for my wireless router for the month. My battery's getting low. Do I want to waste bandwidth and CPU cycles for TLS encoding, just for pictures of shoes? Let's try to turn our focus back to the question at hand, which is whether there are merits to promoting https mirrors for users who have concerns about being watchlisted based on their software choices. I think client cpu cycle and bandwidth concerns are a bit of an anachronism these days anyway. I think you pulled out the only reason why using https for mirrors would be useful. The threat analysis doesn't show any practicable way for the any attacker to prevent alter packages even with control of the network. He could block updates but the client-side would noticed: out-of-date repository and package list, failed to download specific packages. HTTPS is a solution to this risk scenario: A) I don't want anyone to know which package I download (passive listening) B) I don't want a third party to selectively prevent me from downloading a package/update (active man i the middle) Scenario A is more likely to happen or to already be in place. HTTPS in this case is *not* about security but just privacy. 1) Performance concern: The CPU cycles for encrypting is now low enough so that it seems feasible. Not all package providers need to provide https-based repository but having a few of those and give them visibility would be greatly appreciated. 2) TLS certificates: we do not need the package to be behind a debian certificate, just to be behind a certificate trusted by a recognized third party (same requirement as for websites). Since we do not seek authentication of the package but just privacy, we only need to ensure that we talk to the server we wanted to, whichever it is. I'm trying to practice what I preach here, so I set up my very first debian mirror. It is hosted on my home connection, so be gentle. It is only debian-security for amd64 and i386: deb http://dju2peblv7upfz3q.onion/debian-security/ wheezy/updates main This is a test repo, so be sure to keep a real debian-security mirror in your sources.list! Just put it after the above line, and apt-get will prefer the tor hidden service, but still get the latest updates available from debian-security. .hc signature.asc Description: OpenPGP digital signature
Re: concrete steps for improving apt downloading security and privacy
On Mon, Jul 07, 2014 at 02:54:15PM -0400, Hans-Christoph Steiner wrote: Do you have another idea for making it difficult for network observers to keep track of the software people are using? Well, you can always mirror the entire repository and configure your server/desktop to use that instead. That way noone can tell for certain which packages you are using, and as a bonus, you have offline access if your internet connection goes down. I am not sure about the size of it though. Do you think it does not matter that governments and companies are tracking the packages that people are downloading? .hc -- 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/20140708211638.gc24...@noserver.visp.name
Re: the calculus of encrypting non-textual data (was Re: concrete steps for improving apt downloading security and privacy)
Joel Rees dijo [Tue, Jul 08, 2014 at 11:11:09PM +0900]: Did you know that encrypting a picture sometimes results in a picture that looks like it has been through a random color-permuting filter? Can you proof it? Memory of coursework in encryption. The professor did some simple encryption on uncompressed images and showed how the results tended not to hide the things one would want hidden. Then he pointed out that the parts of an image with the most information are the parts that are least likely to compress. And he pointed out that standard encryption methods tend to be byte-oriented, for speed. Well... Yes and no. Yes, that happens when you don't do it right. http://gwolf.org/files/desarrollo_y_cripto.pdf#page=40 If you implement the wrong mode of operation (schemes for the five modes of operation shown in the next page), you end up with the problem you mention. This result was achieved using the Electronic Code Book (ECB). Now, the ECB mode should never be used twice for the same plaintext blocks. Oh, and as a sidenote for my images: They are *a bit* tricked. If you apply ECB to a PNG image, as the PNG image is compressed, you will not find this pattern. I saved the original image as a BMP, then ciphered the image, and then copied over (prepended) the BMP header to the new file; that's the reason for the file to be slightly right-shifted: It contains a bit of unnecessary noise. But the effect *is* correct. He did not require us to do any homework on it, so I don't have any special tools in my notebooks. 30 years ago. Heh. The technology has changed somewhat since then, but I recently read about some standard encrypted sound files that were playable, noisy, but recognizable. Same principle. It is very simple. The implementation is one page earlier in the document I sent you. If you replace i.e. AES-128-ECB with AES-128-OFB (and supply an initialization vector, which does not have such secrecy requirements as the key). -- 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/20140709014205.gj114...@gwolf.org
Re: concrete steps for improving apt downloading security and privacy
2014/07/07 11:32 Lou RUPPERT hims...@louruppert.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT hims...@louruppert.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. Not true. If I'm looking at an https-enabled page, and elements included in the page are http-only, I want to know about it. Why? By the time you're looking at it, there's nothing to do about what has been sent in the clear. It means the site maintainer messed up, and potentially sensitive information is going in the clear despite being included from a web page that is https. https is not a flag for TOP SECRET NSA PLAN FOR BACKDOORING THE UNIVERSE'S COMPUTERS OHS NOES! It means a breach is potentially occurring and that I should stop what I'm doing if the information presented is sensitive. Most of what is sent https is not even classified sensitive. If I'm looking at a catalog page from a shoe store on my table, connected via the phone network, getting close to my 2G cap for my wireless router for the month. My battery's getting low. Do I want to waste bandwidth and CPU cycles for TLS encoding, just for pictures of shoes? I suppose, if I'm looking for shoes for my wife's birthday, and it's supposed to be a surprise, and she regularly analyzes the house's router logs to check whether the kids are going to pornofthemonth.xxx, ..., but that's not the wireless router, come to think of it. Does your wife check your router logs? Okay, I suppose my son might, but, seriously. Oh, I suppose, if I were the kind of person to go to porn sites, I might decide not to return to such a site that sent me it's bd pics plaintext. (Did you know that encrypting a picture sometimes results in a picture that looks like it has been through a random color-permuting filter?) Of course, if someone is tapping my stream and looking at the images I'm looking at, they probably also know what sites I'm connecting to. What I don't want is a site that claims to be 'secure' while leaking. Every site leaks. Secure pages that are blanket-sent TLS for the wrong reasons will not be analyzed for leaks, because the people who design the sight are unaware that TLS is not a big enough blanket. See how Microsoft has been complicit in this particular social engineering scheme from a long time ago? (I thought, back then, that they were just being lazy or trying to meet a stupid market window with incomplete tech again. Naive of me, yes.) Huh? Content creators and site managers probably want a tool that will highlight or red-circle elements on a page that are declared plaintext, and (as a different option or command) elements that will end up plaintext when the page is sent TLS. And they want the tool to walk their site automatically, leaving a log behind. Users want their browser to tell them when parts of the data in the query they send TLS are going to be sent plaintext. Some may want to know which elements are going to be sent plaintext. Some may want to scan for plaintext elements before they start filling in the form, so they don't waste their time. But they don't really care if the picture of the shoe or its title is being received plaintext. Such information is perceived as noise, unless they really are concerned about the off chance that someone might be capturing their data stream to find out what pictures or political rants they are accessing. Apple store or Play store would probably provide a more useful dataset for them anyway. But not so interesting, and not so constant. Sure, enough bits and pieces are separable to extract much of the constant part, but I don't think it's very interesting to the spooks. I mean, I think they already have what they need there pretty early on. We're talking about datasets used to factor keys, right? Surely you see that is not all that we are talking about? If they want to perfect some secret squirrel factoring technique, there are plenty of popular candidates to use. So, give them more data. Give them more of the hard data, in fact. We don't need to worry about debian repos becoming the key that allows them to develop that technique. Really? I mean, the current encryptions will be broken sooner or later. You're voting for sooner? I mean, yes, they are trying various ways to find the keys people are using, but those aren't the big fish. Especially since we have to assume that the hardware entropy generators in the CPUs for the most popular CPUs are pretty much under the control of one set of spooks or another. Yes, but except for freebsd's(?) mistake of using it exclusively, you'll find that OSes mix the entropy sources when providing /dev/random, and that
Re: concrete steps for improving apt downloading security and privacy
On 07/06/2014 10:20 PM, Michael Stone wrote: On Sat, Jul 05, 2014 at 08:54:55AM +0900, Joel Rees wrote: And you know, the funny thing is that MSIE took to warning people when there was a mix of encrypted and unencrypted data on a page. How long ago? Yeah, I know, it was so they could display that red herring of a lock for secured pages. You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. This kind of threat analysis is why so many of us are still skeptical of the need for HTTPS package mirrors. Mike Stone Do you have another idea for making it difficult for network observers to keep track of the software people are using? Do you think it does not matter that governments and companies are tracking the packages that people are downloading? .hc -- 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/53baecd7.3080...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On 07/06/2014 10:31 PM, Lou RUPPERT wrote: Joel Rees: On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT hims...@louruppert.com wrote: As someone pointed out, verifying the mirror we've connected to is not useful when we don't particularly have, or want, a way to prevent a spook-owned mirror from joining the pool. OK so supposing the NSA offers its own mirror. The package installation process verifies PGP signatures. What is the actual scenario you're trying to prevent? apt repositories are great because the users do not have to rely on the servers that host the repositories in order to know that they packages are authentic and unmodified. Tor provides the same resilience in terms of privacy. If apt-get is accessing the NSA mirror using Tor, then even the NSA will not be able to see the IP address of the computer that is downloading from that mirror. And as long as apt does not leak much metadata, it would be quite difficult for the NSA to de-anonymize that connection. .hc signature.asc Description: OpenPGP digital signature
Re: concrete steps for improving apt downloading security and privacy
On 07/07/2014 13:09, Joel Rees wrote: Sorry Joel, I almost totally disagree with your vision on privacy and security, but I really i don't want to go into the merit of it, because I think Lou is representing my vision already; I only have a question: Did you know that encrypting a picture sometimes results in a picture that looks like it has been through a random color-permuting filter? 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). :-) Andrea Zwirner Sent from my Sylpheed image.jpg.gpg Description: Binary data
Re: concrete steps for improving apt downloading security and privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: 2014/07/07 11:32 Lou RUPPERT hims...@louruppert.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT hims...@louruppert.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. Not true. If I'm looking at an https-enabled page, and elements included in the page are http-only, I want to know about it. Why? By the time you're looking at it, there's nothing to do about what has been sent in the clear. There are sites now which have dynamic content. Imagine a site like Facebook, where there is so much content that it can't even fit on one page! As I already explained, the cleartext download warning isn't warning you about the data you're already looking at; it's warning you that the mechanism you're trusting may not be trustworthy. It's telling you stop now unless you understand the problem. Advice I'd recommend! It means the site maintainer messed up, and potentially sensitive information is going in the clear despite being included from a web page that is https. https is not a flag for TOP SECRET NSA PLAN FOR BACKDOORING THE UNIVERSE'S COMPUTERS OHS NOES! Not following you here. It means a breach is potentially occurring and that I should stop what I'm doing if the information presented is sensitive. Most of what is sent https is not even classified sensitive. Agreed. If I'm looking at a catalog page from a shoe store on my table, connected via the phone network, getting close to my 2G cap for my wireless router for the month. My battery's getting low. Do I want to waste bandwidth and CPU cycles for TLS encoding, just for pictures of shoes? Let's try to turn our focus back to the question at hand, which is whether there are merits to promoting https mirrors for users who have concerns about being watchlisted based on their software choices. I think client cpu cycle and bandwidth concerns are a bit of an anachronism these days anyway. Oh, I suppose, if I were the kind of person to go to porn sites, I might decide not to return to such a site that sent me it's bd pics plaintext. (Did you know that encrypting a picture sometimes results in a picture that looks like it has been through a random color-permuting filter?) That's only if you don't include it inside of a stream with a bunch of other content, like http 1.1, for instance. Of course, if someone is tapping my stream and looking at the images I'm looking at, they probably also know what sites I'm connecting to. How about this scenario: Someone is installing software from a software catalog from a country where downloading software isn't illegal, but where people who download certain software are flagged as terrorists and made to undergo certain invasive scrutiny as a result. One catalog has the page served via https, but the software served via http, because they haven't upgraded their servers in a couple decades, and they own a lot of stock in the electric company. The other catalog has the whole content served via https. Which catalog do you think can install something like 'tor' without the user being watchlisted? Now update the scenario for an environment in which the nation state has a DPI border firewall and automatically stops downloads of certain software they don't like. Which catalog do you think will result in the user being able to successfully download what they need? (an interesting side effect from this is that the DPI site may decide to block the entire TLS-only catalog because of the lack of introspection, so maybe defaulting to an https mirror may have unintended consequences in such an environment?) What I don't want is a site that claims to be 'secure' while leaking. Every site leaks. Secure pages that are blanket-sent TLS for the wrong reasons will not be analyzed for leaks, because the people who design the sight are unaware that TLS is not a big enough blanket. Explain, please? Apple store or Play store would probably provide a more useful dataset for them anyway. But not so interesting, and not so constant. Sure, enough bits and pieces are separable to extract much of the constant part, but I don't think it's very interesting to the spooks. I mean, I think they already have what they need there pretty early on. We're talking about datasets used to factor keys, right? Surely you see that is not all that we are talking about? Nope. So what is the risk you're talking about, if not some key factoring plot? If they want to perfect some secret squirrel factoring technique, there are plenty of popular candidates to use. So, give them more data. Give them more of the hard data, in fact. Why
Re: concrete steps for improving apt downloading security and privacy
On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT hims...@louruppert.com wrote: If I'm looking at a catalog page from a shoe store on my table, connected via the phone network, getting close to my 2G cap for my wireless router for the month. My battery's getting low. Do I want to waste bandwidth and CPU cycles for TLS encoding, just for pictures of shoes? Let's try to turn our focus back to the question at hand, which is whether there are merits to promoting https mirrors for users who have concerns about being watchlisted based on their software choices. I think client cpu cycle and bandwidth concerns are a bit of an anachronism these days anyway. I think you pulled out the only reason why using https for mirrors would be useful. The threat analysis doesn't show any practicable way for the any attacker to prevent alter packages even with control of the network. He could block updates but the client-side would noticed: out-of-date repository and package list, failed to download specific packages. HTTPS is a solution to this risk scenario: A) I don't want anyone to know which package I download (passive listening) B) I don't want a third party to selectively prevent me from downloading a package/update (active man i the middle) Scenario A is more likely to happen or to already be in place. HTTPS in this case is *not* about security but just privacy. 1) Performance concern: The CPU cycles for encrypting is now low enough so that it seems feasible. Not all package providers need to provide https-based repository but having a few of those and give them visibility would be greatly appreciated. 2) TLS certificates: we do not need the package to be behind a debian certificate, just to be behind a certificate trusted by a recognized third party (same requirement as for websites). Since we do not seek authentication of the package but just privacy, we only need to ensure that we talk to the server we wanted to, whichever it is. -- Jérémie MARGUERIE -- 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/CAKS89GpjJtSNWcRvy2vJ4Jat97qmqPa2Q-=_x12yipw8qqq...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Sat, Jul 05, 2014 at 08:54:55AM +0900, Joel Rees wrote: And you know, the funny thing is that MSIE took to warning people when there was a mix of encrypted and unencrypted data on a page. How long ago? Yeah, I know, it was so they could display that red herring of a lock for secured pages. You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. This kind of threat analysis is why so many of us are still skeptical of the need for HTTPS package mirrors. 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/37d34a1a-057d-11e4-bb7f-00163eeb5...@msgid.mathom.us
Re: concrete steps for improving apt downloading security and privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT hims...@louruppert.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. Not true. If I'm looking at an https-enabled page, and elements included in the page are http-only, I want to know about it. It means the site maintainer messed up, and potentially sensitive information is going in the clear despite being included from a web page that is https. It means a breach is potentially occurring and that I should stop what I'm doing if the information presented is sensitive. What I don't want is a site that claims to be 'secure' while leaking. See how Microsoft has been complicit in this particular social engineering scheme from a long time ago? (I thought, back then, that they were just being lazy or trying to meet a stupid market window with incomplete tech again. Naive of me, yes.) Huh? Apple store or Play store would probably provide a more useful dataset for them anyway. But not so interesting, and not so constant. Sure, enough bits and pieces are separable to extract much of the constant part, but I don't think it's very interesting to the spooks. I mean, I think they already have what they need there pretty early on. We're talking about datasets used to factor keys, right? If they want to perfect some secret squirrel factoring technique, there are plenty of popular candidates to use. We don't need to worry about debian repos becoming the key that allows them to develop that technique. I mean, yes, they are trying various ways to find the keys people are using, but those aren't the big fish. Especially since we have to assume that the hardware entropy generators in the CPUs for the most popular CPUs are pretty much under the control of one set of spooks or another. Yes, but except for freebsd's(?) mistake of using it exclusively, you'll find that OSes mix the entropy sources when providing /dev/random, and that most processes use a derivative PRNG in /dev/urandom. If you look at the Linux /dev/random implementation, you'll find that a busy site will provide enough noise to reduce the impact of a compromised hwrng. People who care about entropy obtain it from a variety of sources. I mean, yeah, they probably have the resources to simulate the debian download infrastructure in their internal server farms, but why do their work for them and free their resources up for other jobs? I'm not sure that's a realistic scenario. Why not? Factoring/brute-forcing the debian signing keys so that they can simulate debian mirrors when MITMing some poor hapless target is a movie plot threat. They do that for other encrypted streams, like determining successful SSH logins. But TLS also serves as a sort of sloppy authentication mechanism, assuring you that someone someplace has vouched for the fact that you've connected to the system you intended to connect to. It's not terribly useful when you already sign your packages, but layers etc. I myself use the argument of added low walls and speed bumps when we are talking about skript k!dd13s, but low walls are not such a wonderful strategy when we turn our attention to professionals. It's pushing a metaphor, but a low wall can sometimes be another place for a spook to hide. As someone pointed out, verifying the mirror we've connected to is not useful when we don't particularly have, or want, a way to prevent a spook-owned mirror from joining the pool. OK so supposing the NSA offers its own mirror. The package installation process verifies PGP signatures. What is the actual scenario you're trying to prevent? - -- I prefer encrypted email. Get my key here: http://www.louruppert.com/keys/115DCF62.asc PGP Fingerprint: 3261 B9F9 9363 D512 56F8 12DD 127F 4D6A 115D CF62 -BEGIN PGP SIGNATURE- iEYEAREKAAYFAlO6Bn0ACgkQEn9NahFdz2L8kwCgsWX6ldGGzIs2EOMt6vn3KEza KKEAoMvDjTUv9tCO+6vNVOOYo0J07EAm =YzvF -END PGP SIGNATURE- -- 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/53ba0685.9050...@louruppert.com
Re: concrete steps for improving apt downloading security and privacy
On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: [rhetoric encouraging the use of TLS transport for mirrors] [list of current https mirrors] Far be it from me to argue with ucalgary.ca, but one thing that bothers me about using TLS as a download transport is that, if I were the spooks, and I wanted a huge sample of crypts from a known plaintext, I could think of worse ways to go than to get the opensource crowd to provide them for me. I mean, yeah, they probably have the resources to simulate the debian download infrastructure in their internal server farms, but why do their work for them and free their resources up for other jobs? Especially when the only real advantage of using TLS download transport is (the illusion of) being able to download what you want without them knowing exactly what you downloaded. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/CAAr43iOTxVcCGyh5+d4VA43279Np6cKm9=4sq-wl0a1v8j5...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: [rhetoric encouraging the use of TLS transport for mirrors] [list of current https mirrors] Far be it from me to argue with ucalgary.ca, but one thing that bothers me about using TLS as a download transport is that, if I were the spooks, and I wanted a huge sample of crypts from a known plaintext, I could think of worse ways to go than to get the opensource crowd to provide them for me. Any popular site with relatively static content would do that. Apple store or Play store would probably provide a more useful dataset for them anyway. But if you configure it and the clients to favor ephemeral keys you reduce the usefulness of captured traffic in being able to simulate the server itself. I mean, yeah, they probably have the resources to simulate the debian download infrastructure in their internal server farms, but why do their work for them and free their resources up for other jobs? I'm not sure that's a realistic scenario. Especially when the only real advantage of using TLS download transport is (the illusion of) being able to download what you want without them knowing exactly what you downloaded. Yeah they could probably infer it based on the session size. They do that for other encrypted streams, like determining successful SSH logins. But TLS also serves as a sort of sloppy authentication mechanism, assuring you that someone someplace has vouched for the fact that you've connected to the system you intended to connect to. It's not terribly useful when you already sign your packages, but layers etc. - -- I prefer encrypted email. Get my key here: http://www.louruppert.com/keys/115DCF62.asc PGP Fingerprint: 3261 B9F9 9363 D512 56F8 12DD 127F 4D6A 115D CF62 -BEGIN PGP SIGNATURE- iEYEAREKAAYFAlO2y64ACgkQEn9NahFdz2JUNQCgjZChVYQEwELRqLg7uweq86Ee 3IQAoKWjpfzBeTnHpoMbmfirx6N7oMDU =F6xl -END PGP SIGNATURE- -- 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/53b6cbae.4040...@louruppert.com
Re: concrete steps for improving apt downloading security and privacy
On 07/04/2014 11:43 AM, Lou RUPPERT wrote: Joel Rees: On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: [rhetoric encouraging the use of TLS transport for mirrors] [list of current https mirrors] Far be it from me to argue with ucalgary.ca, but one thing that bothers me about using TLS as a download transport is that, if I were the spooks, and I wanted a huge sample of crypts from a known plaintext, I could think of worse ways to go than to get the opensource crowd to provide them for me. Any popular site with relatively static content would do that. Apple store or Play store would probably provide a more useful dataset for them anyway. But if you configure it and the clients to favor ephemeral keys you reduce the usefulness of captured traffic in being able to simulate the server itself. I mean, yeah, they probably have the resources to simulate the debian download infrastructure in their internal server farms, but why do their work for them and free their resources up for other jobs? I'm not sure that's a realistic scenario. Especially when the only real advantage of using TLS download transport is (the illusion of) being able to download what you want without them knowing exactly what you downloaded. Yeah they could probably infer it based on the session size. They do that for other encrypted streams, like determining successful SSH logins. But TLS also serves as a sort of sloppy authentication mechanism, assuring you that someone someplace has vouched for the fact that you've connected to the system you intended to connect to. It's not terribly useful when you already sign your packages, but layers etc. I'm with Lou on this one, there are already much bigger and better data sets for that. According to this paper[1], Fedora 11+, Red Hat, SUSE, Google updates like Chrome and Android tools, Adobe AIR, Firefox, Python pypi, and others all use HTTPS for their updates. Debian is behind the curve here, HTTPS for updates is becoming the norm. Plus if the HTTPS it set up with Forward Secrecy ciphers, the keys are frequently rotated. And on the flipside of Joel's argument, right now, the NSA tries to store as much encrypted data as possible. That way when they get the key later, they can go back and decrypt old traffic. So generating more HTTPS traffic means they can't keep up as much. But this is probably not really important in this case since they would probably notice that the sites are mirrors and ignore the traffic. .hc [1] http://freehaven.net/~arma/tuf-ccs2010.pdf or https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf signature.asc Description: OpenPGP digital signature
Re: concrete steps for improving apt downloading security and privacy
On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT hims...@louruppert.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: [rhetoric encouraging the use of TLS transport for mirrors] [list of current https mirrors] Far be it from me to argue with ucalgary.ca, but one thing that bothers me about using TLS as a download transport is that, if I were the spooks, and I wanted a huge sample of crypts from a known plaintext, I could think of worse ways to go than to get the opensource crowd to provide them for me. Any popular site with relatively static content would do that. And you know, the funny thing is that MSIE took to warning people when there was a mix of encrypted and unencrypted data on a page. How long ago? Yeah, I know, it was so they could display that red herring of a lock for secured pages. You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. See how Microsoft has been complicit in this particular social engineering scheme from a long time ago? (I thought, back then, that they were just being lazy or trying to meet a stupid market window with incomplete tech again. Naive of me, yes.) Apple store or Play store would probably provide a more useful dataset for them anyway. But not so interesting, and not so constant. Sure, enough bits and pieces are separable to extract much of the constant part, but I don't think it's very interesting to the spooks. I mean, I think they already have what they need there pretty early on. But if you configure it and the clients to favor ephemeral keys you reduce the usefulness of captured traffic in being able to simulate the server itself. And give them even more to work from. Sure. I mean, yes, they are trying various ways to find the keys people are using, but those aren't the big fish. Especially since we have to assume that the hardware entropy generators in the CPUs for the most popular CPUs are pretty much under the control of one set of spooks or another. I mean, yeah, they probably have the resources to simulate the debian download infrastructure in their internal server farms, but why do their work for them and free their resources up for other jobs? I'm not sure that's a realistic scenario. Why not? Especially when the only real advantage of using TLS download transport is (the illusion of) being able to download what you want without them knowing exactly what you downloaded. Yeah they could probably infer it based on the session size. Uhm, yeah, that's another trick they have available. But in many cases, they don't even need to do that. They do that for other encrypted streams, like determining successful SSH logins. But TLS also serves as a sort of sloppy authentication mechanism, assuring you that someone someplace has vouched for the fact that you've connected to the system you intended to connect to. It's not terribly useful when you already sign your packages, but layers etc. I myself use the argument of added low walls and speed bumps when we are talking about skript k!dd13s, but low walls are not such a wonderful strategy when we turn our attention to professionals. It's pushing a metaphor, but a low wall can sometimes be another place for a spook to hide. As someone pointed out, verifying the mirror we've connected to is not useful when we don't particularly have, or want, a way to prevent a spook-owned mirror from joining the pool. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/caar43iotff6hdoy7es4pv2jpjcw5zveukfcgpkhrk_n2e+1...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Sat, Jul 5, 2014 at 6:14 AM, Hans-Christoph Steiner h...@at.or.at wrote: [...] I'm with Lou on this one, I'm not surprised. there are already much bigger and better data sets for that. So we should give them even more? According to this paper[1], Fedora 11+, Red Hat, SUSE, Google updates like Chrome and Android tools, Adobe AIR, Firefox, Python pypi, and others all use HTTPS for their updates. Pardon me for being obnoxious, but do you really need to refer to someone else's research[1] for that little gem? Well, I suppose, if we were on the user list, we might assume that some of those participating might not be using those tools, or might not be noticing what they are downloading. In which case, it would be nice, if you were assuming such, to provide a page/paragraph/table/etc. number, such as Table 2, found in section 5, on p. 5 of http://freehaven.net/~arma/tuf-ccs2010.pdf (Or of https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf. I guess the reason you gave me two links to the same paper is so that if one is unreachable we might be able to get to the other?) Debian is behind the curve here, So we aren't fashionable? HTTPS for updates is becoming the norm. Lemmings, everyone? Plus if the HTTPS it set up with Forward Secrecy ciphers, the keys are frequently rotated. The MacGuffins? But what is the Holy Grail for them? (Yeah, Holy Grails are also MacGuffins, but keys are red herring-style MacGuffins here.) And on the flipside of Joel's argument, right now, the NSA tries to store as much encrypted data as possible. They admit as much. That way when they get the key later, they can go back and decrypt old traffic. Do we really think that's the only reason they store it? So generating more HTTPS traffic means they can't keep up as much. Hmm. I wonder which they are going to have an easier time budgeting -- adding more off-line storage or adding more on-line CPUs+storage? You do understand that emulating distribution networks takes CPUs? But this is probably not really important in this case since they would probably notice that the sites are mirrors and ignore the traffic. ??? .hc [1] http://freehaven.net/~arma/tuf-ccs2010.pdf or https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/CAAr43iPovcP-xFj+RKJfeGh4u+YgYKRdRRFEkuw9o9hzAoj=l...@mail.gmail.com
