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
-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
-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
