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
