On 07/04/2014 11:43 AM, Lou RUPPERT wrote: > Joel Rees: >> On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner >> <hans@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
Attachment:
signature.asc
Description: OpenPGP digital signature