6 ms·

Why does APT not use HTTPS?

14 points by lamby 9y ago

dozzie 9y ago
Because it doesn't need encryption (packages' contents are public knowledge), while data integrity is protected by GPG digital signatures. That's why.
- lamby 9y ago
  Does the linked page not say this? :)
- fulafel 9y ago
  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.)
earenndil 9y ago
> 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).
lucideer 9y ago
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 9y ago
  > 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 9y ago
    > 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 9y ago
      >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.
jwilk 9y ago
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 9y ago
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. :-(
ageisp0lis 9y ago
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?
tinus_hn 9y ago
The obvious problem is that Debian is not in a position to demand https support from the companies that provide them with free bandwidth.
ashleyn 9y ago
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 9y ago
  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.
paulddraper 9y ago
What is not directly mentioned: signing packages allows you to use hosts, mirrors, etc. without trusting them. HTTPS cannot give you that.
- creatonez 9y ago
  I don't think anyone's suggesting replacing package signing with HTTPS.
  - paulddraper 9y ago
    Oh...well that's why the page was written: why signing gets us everything HTTPS would (and more).
fulafel 9y ago
> 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.

14 points by lamby 9y ago

Because it doesn't need encryption (packages' contents are public knowledge), while data integrity is protected by GPG digital signatures. That's why.

lamby 9y ago
Does the linked page not say this? :)
fulafel 9y ago
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.)

earenndil 9y ago

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

lucideer 9y ago

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 9y ago
> 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 9y ago
  > 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 9y ago
    >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.

jwilk 9y ago

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 9y ago

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. :-(

ageisp0lis 9y ago

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?

tinus_hn 9y ago

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

ashleyn 9y ago

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 9y ago
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.

paulddraper 9y ago

What is not directly mentioned: signing packages allows you to use hosts, mirrors, etc. without trusting them. HTTPS cannot give you that.

creatonez 9y ago
I don't think anyone's suggesting replacing package signing with HTTPS.
- paulddraper 9y ago
  Oh...well that's why the page was written: why signing gets us everything HTTPS would (and more).

fulafel 9y ago

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