On Jul 3, 2014, at 12:10 PM, Hans-Christoph Steiner wrote: > > On Jul 3, 2014, at 11:52 AM, Michael Stone wrote: > >> On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote: >>> I definitely agree there are legitimate concerns that using HTTPS on apt >>> mirrors would help, and people who suggest otherwise are out of date on >>> what the threats are. I think the integrity of the package itself is not >>> reason enough to use HTTPS since the GPG signing is much more reliable for >>> that task. I break it down into 4 >>> >>> 1. package authenticity >>> (software can be modified while being downloaded) >>> >>> 2. repo availability >>> (internet services can be blocked by governments and companies) >>> >>> 3. package availability >>> (software security updates can be individually blocked) >>> >>> 4. who’s downloading what package (currently visible to anyone who can see >>> the network traffic, including open wifi, etc.) >>> >>> >>> The current apt model covers #1 well, but only covers #2 and #3 with a two >>> week window (the expiration date on the repo metadata). And it does not >>> cover #4 at all. >> >> HTTPS won't address #1 completely in the presence of mirrors, and debian >> doens't have the resources to serve all users without mirrors. It will not >> address #2. It may address #3, but less reliably than the current siutation. >> It may make #4 harder for certain scenarios, but not others (traffic >> analysis of specific host). >> >> Something like tor will be a better solution for #2, & #4 while the current >> system provides #1 & #3. (And also provides #2 for all practical purposes, >> given the length of the mirror list.) >> >> Mike Stone > > You are correct that HTTPS would not entirely address #2, but it does improve > the situation over HTTP. For example, an ISP, network operator, or > government could block an entire mirror or all mirrors by redirecting > requests to their own mirror which does not get updates. That would be > transparent to the user. This would make for a two week block on all updates > (until the repo data expires). Using Using HTTPS and/or Tor with an onion > address makes that a lot more difficult to do. Just connecting to an HTTP > mirror via Tor would not prevent this. > > But HTTP, HTTPS, and Tor are all in the same boat when all network traffic to > the mirrors are blocked. > > .hc
As for how to manage making HTTPS by default, this does not require every mirror buying HTTPS certificates every year from Certificate Authorities. There are workable solutions based on self-signed certificates. In Android apps, there are two approaches that are gaining traction: including certificate pins based on the Subject Public Key Info (SPKI) in an apt in advance (https://www.imperialviolet.org/2011/05/04/pinning.html). And using "Trust On First Use/Persistence of Pseudonym" aka "Memorizing Trust Manager" (https://github.com/ge0rg/MemorizingTrustManager) to do ssh-style trust with a yes/no prompt the first time. These can also be optionally combined with the classic Certificate Authority, to provide a redundant check. We've been thinking about to make this workable, here are some notes: https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification Or there could be a password-based CA-replacement like http://tack.io .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/cd4e3945-532a-4dad-9cfa-4742dfdcf...@at.or.at
