Re: Debian mirrors and MITM
On Jul 3, 2014, at 11:05 AM, Hans-Christoph Steiner wrote:
> On May 30, 2014, at 10:06 AM, micah anderson wrote:
>> Kurt Roeckx <email@example.com> writes:
>>> On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote:
>>>> On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote:
>>>>> On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote:
>>>>>> The public Debian mirrors seem like an obvious target for governments to
>>>>>> MITM. I know that the MD5s are also published, but unless you're
>>>>>> verifying them with third parties, what's stopping the MD5s being
>>>>>> compromised too?
>>>>> The cryptographic signatures that are validated automatically by apt.
>>>> What's stopping the attacker from serving a compromised apt?
>>> apt will check that the new apt is properly signed.
>> This entire secure artifice depends entirely on the integrity of
>> apt, and presumably the various libraries that it depends on.
>> Now I don't want to call into question the esteemed authors of said
>> program, and depending libraries, but I do think that providing https
>> mirrors gives us two distinct advantages over plain http:
>> . in the case that there is a bug in apt, or gpg, or something
>> else, having https would provide at minimum a minor set of
>> defense against bulk, non-targeted quantum insert and foxacid
>> attacks, not to mention MiTM compromises from a hostile local
>> . keeps an adversary who may be listening on the wire from
>> looking at what you are installing. who cares what you are
>> installing? well it turns out that is very interesting
>> information. If you can see that I've just installed X package,
>> and you then just look over at our security tracker and find
>> that this package has an exploit...
> 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.
> Using HTTPS for apt repos is a simple way to improve the security of all 4. It adds a weak backup security layer for #1, it makes it much more difficult for the attacker to do #2, #3, and #4.
> For those who want to find HTTPS mirrors, try my script here:
I should add: apt-transport-tor is a great project to improve this situation as well that is probably more secure than HTTPS, but at a cost of probably much slower download speeds. Using an apt mirror with an onion address would entirely supplant HTTPS.
So don't get me wrong, I don't think HTTPS is a great system, what I'm saying is that the current state of apt mirrors (HTTP and GPG signing) is not enough. HTTPS can help, especially when used with some kind of certificate/SPKI pinning. Tor can help too, especially when used with onion addresses.