Re: Debian mirrors and MITM
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
Reply to: