Why does APT not use HTTPS?
whydoesaptnotusehttps.com
whydoesaptnotusehttps.com
> But what about privacy?
> HTTPS does not provide meaningful privacy for obtaining packages.
Subjective/wrong. HTTPS does not provide bulletproof privacy, but as defence in depth (also mentioned later) the privacy offered is always of value.
> HTTPS would therefore only be useful for downloading from a server that also offers other packages of similar or identical size.
Which sounds exactly like any typically large software repository, no? Even if the use of it slightly decreases the chance of having an easily parsable/cross-referencable listing if packages a user has installed.
> Overly trusting CAs
This section amounts to a general attack on HTTPS in general, as used on the web. If this were to be followed through, the author would be contending that browsers should stop using HTTPS.
> providing a huge worldwide mirror network available over SSL is not only a complicated engineering task
"Security is hard, so let's not bother"
> it implies a misleading level of security and privacy to end-users as described above.
As described where? Nothing previous in the article mentioned users being misled. Unless the implication is that users believe HTTPS hides the host they're visiting. In which case, again, is the author arguing that HTTPS should be deprecated in its entirety.
Basically, none of the arguments seem to apply exclusively to apt: they seem general criticisms of HTTPS as a whole. Some are even valid criticisms, but none would convince me to advocate for browsers dropping HTTPS. Apt is not special in this regard.
Well they mentioned it in the tl-dr itself. Apt files are already being checked for tampering. This makes it 'special' compared to regular files being downloaded or content being served. Moving to HTTPS doesn't add any extra layer of security in that regard.
Can you articulate what benefits it would bring?
>"Security is hard, so let's not bother"
When you ship your software, does your bug tracker show zero bugs?
Only if you see HTTPS as a proposed alternative to / replacement for signing. Signing content is of course a great security measure - doing one does not preclude doing both.
> Moving to HTTPS doesn't add any extra layer of security in that regard.
This is what the article contends. I rebutted this in my comment above. Of course HTTPS should not replace signing, but it does add an extra layer of security.
> Can you articulate what benefits it would bring?
Firstly, privacy. Not bulletproof, but the article contends that it does not provide "meaningful" privacy which is not true. Secondly, an extra line of defense in addition to signing. As others have commented here, signing is not comprehensive in practice on a per-package basis.
> When you ship your software, does your bug tracker show zero bugs?
No, but a bug left open in a bug tracker indicates an intent to fix. This one is being marked WONTFIX, which is not OK.
Which part is not true?
>As others have commented here, signing is not comprehensive in practice on a per-package basis.
Great, lets fix that. It is orthogonal to HTTPS. Anything else?
>No, but a bug left open in a bug tracker indicates an intent to fix.
It also indicates that it did not have a low cost/benefit ratio.
>This one is being marked WONTFIX, which is not OK.
This point is already addressed under the "Why not provide HTTPS anyway?" section which points to the costs. This indicates strongly that the decision is about cost/benefit. If you have any ideas to lower the costs, propose them. I guess it would first require you to get familiar with all of the ground level logistical details, so maybe an unfair request.
Exactly. This is a privacy concern. Anyone with the ability to sniff connections should not know what I'm downloading (although it may be possible to do package size, and also it might be possible to tell what I'm updating just based on when I update and when was the last time I updated and seeing which packages updated in between those times).
https://bugs.debian.org/863317
Given the amount of time I spent on researching this bug (I tried literally the first thing that came to my mind and it worked), I suspect there's a lot more security bugs in APT lurking.
https://lists.debian.org/53B6150A.3000602@at.or.at
Besides that, https://deb.debian.org/ provides HTTPS mirrors backed by CDNs.
I don't know how to get http://debug.mirrors.debian.org/debian-debug/ over HTTPS though. :-(
This can be remedied by using byte ranges, pipelining and multiplexing.
HTTPS cannot give you that.
First of all, most folks are only signing the Release file. The majority aren't doing debsign/debsigs or dpkg-sig. Okay, some packages ship with some md5sums. Not all. I'm not too worried about tampering or integrity of .deb contents.
How do I know I can trust the Debian archive signing key is in safe hands? For that matter, what about the many third-party repositories and keys that are trusted by my system? Not long ago, Ubuntu was trusting a 1024-bit DSA key. All I need to do is steal or brute-force one of these, and combine it with techniques available to state-level or network adversaries (think of NSA's QUANTUM-insert). Maybe some DNS poisoning or hijacking. Now when you ask for a package you need, I'm giving you my malicious repository instead.
Hostname validation is an important property. Let's say I have a large-scale network where I control the main DNS server, and I can modify records that come from more authoritative sources. I point deb.debian.org and security.debian.org to some other boxes and now no one is getting package updates. Now I have everyone in a more vulnerable state, from which I can figure out more ways to compromise them.
What about the individual package maintainers, can I trust them? Nevermind a distribution like Debian which probably has formal security review. What's to stop one unscrupulous person from being paid to insert a temporary backdoor? Well, that's not so much related to TLS.
> HTTPS does not provide meaningful privacy for obtaining packages.
False.
As mentioned by other commenters, fingerprinting and profiling of the machine — which versions of which packages are installed in the environment — is a real risk which has been demonstrated in practice by researchers. As you mention, the transfer sizes are a mild indicator; not a strong one. But the bar is orders of magnitude higher to identify what's running on a server with apt-transport-https.
Deep packet inspection and Narus is a thing. You're assuming HTTPS is not valuable because the average end user isn't at risk — advanced attackers aren't in their threat model. But when you have machines that both need to be kept highly secure and run a highly specific set of packages, it's absolutely necessary. Imagine I'm an intelligence agency and I'm in that advantaged position where I can see every HTTP GET in plaintext before it hits the official repository, from every client globally. I'm looking for a needle in a haystack: a set or series of packages installed in a certain order. It's trivial now to find my target and learn its IP address.
You're the current project leader... is this page the official stance of Debian?
(No. Nor the official stance of the APT or mirror maintainers. Or even my personal stance!)
Consider the high profile case of sysadmin targeting in the Belgacom case. Hypothetically, GCHQ could then easily fingerprint what versions of apps they are using, and use that information in the plan to target that person.
(HTTPS is still vulnerable to traffic analysis, but a good client can hamper HTTPS traffic analysis using byte range requests and request pipelining/multiplexing.)