
Why does APT not use HTTPS? - lamby
https://whydoesaptnotusehttps.com/
======
lucideer
This website does well to present all the relevant questions, but the answers
are unconvincing.

> _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.

~~~
ksk
> 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?

~~~
lucideer
> _Apt files are already being checked for tampering. This makes it 'special'
> compared to regular files being downloaded or content being served._

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.

~~~
ksk
>but the article contends that it does not provide "meaningful" privacy which
is not true.

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.

------
earenndil
> HTTPS is used to prevent intruders from being able to listen to
> communications between you and websites you visit, as well as to avoid data
> being modified without your knowledge.

 _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).

------
jwilk
APT does not (or did not when I last checked) protect you from replay attacks:

[https://bugs.debian.org/863317](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.

------
jwilk
Some mirrors already support HTTPS, but Debian doesn't advertise this. An
incomplete, possibly out-of-date list is here:

[https://lists.debian.org/53B6150A.3000602@at.or.at](https://lists.debian.org/53B6150A.3000602@at.or.at)

Besides that, [https://deb.debian.org/](https://deb.debian.org/) provides
HTTPS mirrors backed by CDNs.

I don't know how to get [http://debug.mirrors.debian.org/debian-
debug/](http://debug.mirrors.debian.org/debian-debug/) over HTTPS though. :-(

------
fulafel
> Furthermore, even over an encrypted connection it is not difficult to figure
> out which files you are downloading based on the size of the transfer.

This can be remedied by using byte ranges, pipelining and multiplexing.

------
paulddraper
What is not directly mentioned: signing packages allows you to use hosts,
mirrors, etc. without trusting them.

HTTPS cannot give you that.

~~~
creatonez
I don't think anyone's suggesting replacing package signing with HTTPS.

~~~
paulddraper
Oh...well that's why the page was written: why signing gets us everything
HTTPS would (and more).

------
ageisp0lis
I feel that you're significantly understating the potential of what
sophisticated network-level attackers can do here. It's annoying... I
fundamentally disagree that there's "little point" to this.

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?

~~~
lamby
> is this page the official stance of Debian?

(No. Nor the official stance of the APT or mirror maintainers. Or even my
personal stance!)

------
ashleyn
Forget HTTPS: why doesn't apt support any form of threaded installation? On
long updates it looks so wasteful to see one package installed at a time,
probably when it doesn't always need to be that way.

~~~
jwilk
No, dpkg doesn't support this. I doubt installing stuff in parallel would help
anyway. The primary reason it's slow, is that dpkg fsync()s like crazy. Run it
under eatmydata, and it'll be _much_ faster.

------
tinus_hn
The obvious problem is that Debian is not in a position to demand https
support from the companies that provide them with free bandwidth.

------
dozzie
Because it doesn't need _encryption_ (packages' contents are public
knowledge), while _data integrity_ is protected by GPG digital signatures.
That's why.

~~~
fulafel
If you see what packages and security updates a host is downloading, you can
tell a lot about its role, what the user is doing and what to attack.

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.)

