27 ms·

Why does APT not use HTTPS?

515 points by rishabhd 8y ago

skrause 8y ago
Even though the packages are signed cryptographically, there are possible risks when using an unencrypted connection. A man-in-the-middle attack could simply work by serving you a signed, but outdated packages list, preventing your distribution from updating and leaving you vulnerable to security holes. It's the same attack an evil mirror could do as well. So if you want to be really sure you should probably use two independent mirrors over an HTTPS connection.
- niea_11 8y ago
  The website mentions this towards the end (Replay attacks) : To mitigate this problem, APT archives includes a timestamp after which all the files are considered stale The time stamp is described here[1], but it is not clear how the expiration date is decided. 1: https://wiki.debian.org/DebianRepository/Format#Date.2C_Valid-Until https://wiki.debian.org/DebianRepository/Format#Date.2C_Vali...
  - julian-klode 8y ago
    Well, defining the expiration date is up to the server. Debian picks a week. Ubuntu does not use it, I have started a launchpad branch last year, but um, I don't know launchpad, so it might take some more years ;)
- philjohn 8y ago
  They cover this - timestamps are embedded in the packages, and also signed. If they're too old it won't update and you'll know something is amiss.
  - na412 8y ago
    More precisely, an expiration timestamp is embedded in the repository metadata. Packages in debian and derivatives are not signed. Instead, the manifest that lists all the available packages and their checksums is signed. That's also where the expiration data is stored.
    - JdeBP 8y ago
      Even more precisely still, not even the lists of packages are signed. Only InRelease and Release are signed, and they only contain the list of Package files. It's FreeBSD that has the approach of just one signed file containing everything. APT has moved closer to it over the years, but it is not there yet. * https://unix.stackexchange.com/a/332441/5132 https://unix.stackexchange.com/a/332441/5132
mjevans 8y ago
It doesn't need to, the actual security is implemented on a per-package basis. https://wiki.debian.org/SecureApt#How_to_manually_check_for_package.27s_integrity https://wiki.debian.org/SecureApt#How_to_manually_check_for_...
- Tepix 8y ago
  You may not want to make it too easy to find out which packages you have installed.
dvfjsdhgfv 8y ago
I feel the HTTPS hysteria is going too far. For some strange reason people started to consider it a security panacea, without often understanding its limitations. Accusations against APT are a perfect example (it's built-in security mechanisms are superior to what HTTPS has to offer).
- Ensorceled 8y ago
  That’s like saying I don’t need a helmet because I have all of this body armour. At a minimum, HTTPS prevents leakage of information about your configuration but there are several direct attack vectors listed in other threads. Please stop calling it “hysteria”.
  - dvfjsdhgfv 8y ago
    > Please stop calling it “hysteria”. From https://www.beauzee.fr/2017/07/04/videolan-and-https/ https://www.beauzee.fr/2017/07/04/videolan-and-https/: > If you use homosexuality in order to insult/make fun of someone, it is homophobic. You might disagree, but that’s irrelevant. It is. Calling members of the projet on their personal phones and insulting them is probably a bit of an overreaction, don’t you think?
- chii 8y ago
  Secure against modification, is not the same as secure against information leakage and privacy. Using a non-encrypted connection means that it's trivial to work out what packages you download. Using a secure connection at least makes it 1 step harder to infer that information. However, whether packages should be kept private is all-together another question. I argue that OS updates and packages related to that do not need to be kept private, but applications packages do.
  - dvfjsdhgfv 8y ago
    > Using a non-encrypted connection means that it's trivial to work out what packages you download. Using a secure connection at least makes it 1 step harder to infer that information. It is trivial still in the case of APT. That's exactly my point: people start believing HTTPS will protect them against many attack vectors it doesn't. That's OK for uninformed people to believe in the magic of a padlock in the address bar, but technical folks should really know better. If I have access to your network traffic and intend to see which packages you download by apt, I will do it irrespective of whether you use HTTPS or not.
SparklingCotton 8y ago
These reasons make no sense. - SSL certs are hilariously simple with Let's encrypt. - Pretending privacy is a non-issue by saying SSL has the same is stupid, and is it even true with pipelining and HTTP/2 ? Also this excuse conflates the transport layer security with the upper protocols! - "False sense of security". FFS! This excuse could be used for basically ALL SSL protected services, like Ycombinator or Facebook! I thought Debian developers' brains would be bigger than this.
- sschueller 8y ago
  Let's encrypt is also "hilariously" centralised. What do you do if Let's encrypt is blocked in your country or they refuse to issue you a certificate because of US sanctions?
  - lolc 8y ago
    Block Let's Encrypt? How would that even work? They'd have to block all addresses where the webserver uses Let's Encrypt certificates. Or MITM your SSL connections. If Let's Encrypt is blocked, you're not getting the full Internet. Complain with your ISP or government if they do that! If Let's Encrypt refuses to cert your domains, got to another provider. They're not the only one.
    - amaccuish 8y ago
      > They'd have to block all addresses where the webserver uses Let's Encrypt certificates. They're talking about blocking access to letsencrypt servers, which would prevent you from getting a certificate.
      - lolc 8y ago
        Oh. That exists? I still don't see how that would be a problem Debian should consider in their considertions around SSL. After all, if your server's upstream is blocks access to Let's Encrypt servers, why are you trying to operate an official Debian mirror there? What's the point of having a Debian mirror connected to such a shitty upstream?
TorKlingberg 8y ago
The arguments are correct. APT does not need HTTPS to be secure. That said, if APT was designed today I'm sure it would use HTTPS. It's now the default things to do, and Let's Encrypt makes it free and easy. However Debian, where APT is from, relies on the goodwill of various universities and companies to host their packages for free. I can see that they don't want to make demands on a service they get for free, when HTTPS isn't even necessary for the use case. Also since APT and Debian was created in the pre-universal HTTPS days, it does things like map something.debian.org to various mirrors owned by different parties. That makes certificate handling complicated.
- stefan_ 8y ago
  Why would it? As the site lays out, HTTPS is strictly inferior to the scheme used by APT. You can not get more security by adding a less secure mechanism to a better one. It's not additive.
  - julian-klode 8y ago
    Of course you'd get more security. Analogy: It's like your hanging on a rope and also add a safety net. If the rope breaks, you only fall on the safety net instead of the ground. All software has bugs, so if you add two buggy security solutions, you might only be able to exploit a bug in one, but the other still gives you the safety.
    - kiallmacinnes 8y ago
      That's not always true though, and it can be really hard to tell if a particular combination is going to make things better or worse. e.g. the "Breach" HTTPS+Compression vulnerability. To continue your analogy: The rope gets tangled in the safety net, forcing you to jump or proceed up with a loose rope, because you can no longer move the rope..
    - marcosdumay 8y ago
      This is not the physical world. Digital security strength is measured on orders of magnitude, and two mechanisms providing security with very different orders of magnitude do not add in any practical sense.
mgliwka 8y ago
>This can lead to a replay attack where an attacker substitutes an archive with an earlier—unmodified—version of the archive. This would prevent APT from noticing new security updates which they could then exploit. >To mitigate this problem, APT archives includes a timestamp after which all the files are considered stale[4]. Let's take a look at the repo spec then: https://wiki.debian.org/DebianRepository/Format#Date.2C_Valid-Until https://wiki.debian.org/DebianRepository/Format#Date.2C_Vali... > The Valid-Until field may specify at which time the Release file should be considered expired by the client. Client behaviour on expired Release files is unspecified. “Should”, “may”, and unspecified behaviour.
- cbhl 8y ago
  Well, of course the client behavior is under-specified -- sometimes the client is a human constructing a URL to download a .deb in a web browser over a corp-approved proxy, and then hand-installing the package with `deb -i`, bypassing all the security checks. Or sometimes there's a caching proxy (or three) between the client and the server. Or maybe IT has modified apt to only connect to repositories maintained by the IT department, and rejects sources from other domains.
avar 8y 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" Is it really not difficult? I bet if you sorted all the ".deb" packages on a mirror by size a lot of them would have a similar or the same size, so you wouldn't be able to tell them apart based on the size of the dialog. Furthermore, when I update Debian I usually have to download some updates and N number of packages. I don't know if this is now done with a single keep-alive connection. If it is, then figuring out what combination of data was downloaded gets a lot harder. Finally, this out of hand dismisses a now trivial attack (just sniff URLs being downloaded with tcpdump) by pointing out that a much harder attack is theoretically possible by a really dedicated attacker. Now if you use Debian your local admin can see you're downloading Tux racer, but they're very unlikely to be dedicated enough to figure out from downloaded https sizes what package you retrieved.
- ianbooker 8y 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" >> "Is it really not difficult? I bet if you sorted all the ".deb" packages on a mirror by size a lot of them would have a similar or the same size, so you wouldn't be able to tell them apart based on the size of the dialog." Human readable sizes: Sure. Byte size info: Not so much. And even if: Things would become very clear to the attacker after one update cycle for each package. If you really want to mitigate information about downloaded packages you would have to completely revamp apt to randomize package names and sizes, and also randomize read access on mirrors...
  - shasheene 8y ago
    > If you really want to mitigate information about downloaded packages you would have to completely revamp apt to randomize package names and sizes, and also randomize read access on mirrors... There isn't a need to randomize package names, or randomize read access on the mirror, given fetching deb files from a remote HTTP apt repository is a series of GET requests. Randomizing order of these requests can be done completely on the client side. Package sizes are still problematic. Here's a suggestion: if each deb file was padded to nearest megabyte, and there was a handful of fixed-size files (say, 1MB, 10MB and 100MB), the apt-get client could request a suitably small number of the padding files with each download. This would improve privacy with a minimum of software changes and bandwidth wastage.
Theodores 8y ago
Do we now have a custom domain name on a per article basis? I find it strange to have a site that is just about one thing that is not that important to most people on a custom domain. If there were pages and pages of information then yes this might make sense but there isn't. Coming soon... howtotieyourownshoelaces.com The premise of this article per domain reminds me of 1998 when everyone thought that instead of search engines people would be typing in URLs, e.g. 'yescupofteaplease.com' so URLs like 'pets.com' were seen as goldmines-to-be.
- JdeBP 8y ago
  Enjoy http://islinuxaboutchoice.com/ http://islinuxaboutchoice.com/ and http://heartbleed.com/ http://heartbleed.com/ . (-:
- dooglius 8y ago
  I see it as more akin to a vanity plate; no one expects it to be functionally useful, but it's something people will see and so it is somewhat decorative to put something there.
feikname 8y ago
Even though replay attacks will be of no use after some time, one could MITM during the vulnerable timeframe to prevent a critical (0day) security update from happening and therefore gaining control over the system, so if you're specially targetable, I believe it's totally worth switching to an HTTPS mirror instead. Other than that, most should be safe ig. One annoying thing is that the page name is misleading. apt does use/support https, it's just that Debian chooses for its default mirrors to it be optional.
- j16sdiz 8y ago
  If the attacker can MITM you, he can block your access too.
  - feikname 8y ago
    Blocking your access is very noticeable, not having one package upgrade is not.
nurettin 8y ago
reminds me of this http://n-gate.com/software/2017/07/12/0/ http://n-gate.com/software/2017/07/12/0/
giancarlostoro 8y ago
Another scary thing is that despite not including it, when you do have a need for it you're advised to install apt-transport-https[0]. I can't remember the specific package that requires me to go this route, but it always reminds me "oh they're not using https", I'm surprised they don't pull over SSH or something, doesn't git work with SSH as well? [0]: https://packages.debian.org/sid/apt-transport-https https://packages.debian.org/sid/apt-transport-https Edit: It was VSCode: https://code.visualstudio.com/docs/setup/linux https://code.visualstudio.com/docs/setup/linux So Microsoft provides apt packages over https, but Debian doesn't.
- chungy 8y ago
  > So Microsoft provides apt packages over https, but Debian doesn't. See https://deb.debian.org/ https://deb.debian.org/ -- it works just fine. HTTPS might prevent some kind of surveillance, entities (ISPs, governments, any other MITMs) from determining what kind of packages you're installing, and this might be beneficial, but plain old unencrypted HTTP is often faster if these aren't a big concern (they likely aren't in most developed nations and for most occupations). Lack of encryption overhead as well as transparent proxies being able to serve files are huge boons to this.
  - dTal 8y ago
    The article points out that HTTPS offers almost no protection against this kind of surveillance, since packages are almost uniquely identifiable by size.
    - zaarn 8y ago
      With HTTPS you would be able to use HTTP/2 which means you can multiplex a single connection and once you download more than 2 packages, identifying which you installed is impossible. With plain HTTP it remains possible no matter how much pipelining you do.
      - icebraining 8y ago
pksadiq 8y ago
APT many not be using HTTPS. But APT does support HTTPS builtin since version 1.5. I couldn't find any changelog or NEWS for that, but https://packages.debian.org/sid/apt-transport-https https://packages.debian.org/sid/apt-transport-https says so. I myself uses HTTPS mirror provided by Amazon aws (https://cdn-aws.deb.debian.org/ https://cdn-aws.deb.debian.org/). I do so because My ISP sometimes forward to it's login page when I browse HTTP URLs. Also, it does sometime include Ads (Yeah, it's really bad, but it does remind me that I'm being watched).
- RidingPegasus 8y ago
  I watched this blow up on infosec twitter and it made no sense, APT has https or even Tor if you really insist on it. Takes 30 seconds to configure. Storm in a teacup.
  - yrf 8y ago
    infosec twitter is crap like any other twitter subculture, full of drama queens and clickbait to increase their fav/rt count. What's even sadder is that they make no money off it.
    - eqqn 8y ago
      Indeed, something similar happened just last week. theHacker News(not to be confused with HN) twitter lashed out at VLC for not updating over https, which essentially uses same(ish?) code signing as described by APT. A bit of a shit show.
      - deleted 8y ago
        [deleted]
      - detaro 8y ago
        HN also had a big thread participating in the fray... I'm seriously tempted to start flagging links that point to "bad"/"outrage" bugtracker decisions like this, wide public distribution seems to make things quite a bit worse.
gralx 8y ago
https://onion.debian.org/ https://onion.debian.org/ Scroll to the end for a very simple how-to.
kiallmacinnes 8y ago
One thing that wasn't touched on - the mirror network. There are 100's of mirrors for all the major distros ran by third parties, if e.g. Debian wanted apt over HTTPS, they would need to hand out a debian.org SSL cert+key to all of them. (And convince them all to take the CPU overhead hit of TLS) EDIT: Since I can't reply to all the downvoters, I'll add here.. LetsEncrypt does not solve this. http://us.archive.ubuntu.com/ http://us.archive.ubuntu.com/ - that goes to likely 10's of different mirrors. Which one will the LetsEncrypt verification call hit?
- majewsky 8y ago
  So? In the age of Let's Encrypt, this task is (or rather, should be) downright trivial. Source: Using multiple dozens of LE-issued certs without even thinking about it.
- zaarn 8y ago
  What? No. The mirrors would just need to install a letsencrypt-compatible client and setup SSL via that. On any modern CPU since 2011 or so, TLS overhead is below a percent and a decent cheap dedicated box should be able to saturate a 1 Gbps uplink.
  - toast0 8y ago
    Actually, no, the mirrors may not be able to verify themselves with let's encrypt. A hostname like ftp.us.debian.org resolves to many different mirrors, and may not resolve consistently around the world -- if that's the case, let's encrypt will not be able to verify the hosts through http challenges. Also, 1gbps is pretty small. I can't find any documentation on traffic, but I'd imagine mirrors in popular places are at least on 10gig.
    - zaarn 8y ago
      I have a 10Gbps uplink on my personal server and I can easily saturate it without getting capped on CPU or RAM. LE offers other challenges to verify hosts, like DNS verification. DNS verification can be done easily with an external API for mirror owners to hit (most ACME clients offer DNS challenge with the standard update protocol for DNS which can be secure appropriately).
BetaCygni 8y ago
I don't care for home-brew security, I need something standard. Also... the firewall at work breaks APT HTTP pipelining. Very very annoying. It would not be able to do so if APT was using HTTPS.
- kiallmacinnes 8y ago
  The signature method used by Linux mirrors has existed longer than HTTPS has, there's nothing homebrew about it.
  - BetaCygni 8y ago
    I trust the file signatures, but if you need to write a full article arguing something is secure then it can be made more secure by making the system simpler and more standard.
    - pritambaral 8y ago
      The apt system is simpler. HTTPS is merely more popular, and breaks existing apt use-cases.
    - widforss 8y ago
      You are going to become very upset when you discover the simplicity of TLS.
- xorcist 8y ago
  > It would not be able to do so if APT was using HTTPS. Oh, you are in for a surprise when you find out what middleboxes really do these days.
lucideer 8y ago
TL;DR > providing a huge worldwide mirror network available over SSL is [...] a complicated engineering task > A switch to HTTPS would also mean you could not take advantage of local proxy servers
- kiwijamo 8y ago
  My local Debian mirrors support HTTPS, and I assume other mirror sites worth their salt do too. Easy enough for Debian to redirect to your local mirror.
  - pritambaral 8y ago
    The local apt-cacher-ng instance I run in my office network cannot be redirected to by Debian, because cannot be aware of it. The apt client will need to build support for local proxies. As it stands right now, apt-cacher-ng cannot work with https sources.
    - snuxoll 8y ago
      Fedora handles this use case beautifully with MirrorManager, which includes the EPEL repos as well. All of the logic is server side, when a yum/dnf client connects to the Metalink server to fetch a mirror list from our IP block it gets sent our internal mirror - I wish more distros had similar setups.
      - pritambaral 8y ago
        So, the public metalink server is aware of your internal mirror?
        snuxoll 8y ago
        Yes, the mirror is configured as private and is only served to machines in my IP range - since it’s on the internal network it does nobody else good to have access.
LeonidasXIV 8y ago
Yes, I just love Debian not being able to update libsexy2 because some stupid filtering box blocks "sex" in URLs.
Dormeno 8y ago
One important factor this article left out is upgrades. If the given HTTPS implementation is broken because of what is now insecure protocols, insecure ciphers etc. Older systems can't update from the mirror if it's updated to use a 'secure' HTTPS configuration while it only supports the 'vulnerable' solution. If HTTPS is left insecure, then it is not much different from using HTTP. APT's methodology avoids this and as the current signing and protection mechanisms are file based, the worst case scenario is introducing a new file with a new cryptographic signature along side the old schema, to support still updating a system running old security mechanism. In comparison, trying to run multiple HTTPS servers with different configurations for specific versions of the system being updated would be a significant engineering effort, especially for mirrors.
- da_chicken 8y ago
  Huh? All you would do is configure the web server running your apt mirror site to serve the same content on both HTTP and HTTPS ports. If the client want to use TLS, they connect to HTTPS. If they want to use plain HTTP, they connect to HTTP. Both sites serve the same content, which is just a series of flat files. AFAIK, the client is responsible for determining the correct versions for the installed distro based on the indices. This is what many mirrors already do: http://mirrors.lug.mtu.edu/debian/ http://mirrors.lug.mtu.edu/debian/ https://mirrors.lug.mtu.edu/debian/ https://mirrors.lug.mtu.edu/debian/
  - toast0 8y ago
    If your installed version is configured for https, but is incapable of using TLS 1.2, because it's rather old, at some point soon, a modern mirror would no longer allow it to connect as 2019 (or maybe 2020) seems to be shaping up as the year to kill support for TLS 1.0 and 1.1. Meanwhile, an http config would continue to work.
aboutruby 8y ago
Should be HTTPS by default just for the privacy of downloading packages without any intermediaries knowing the package names. It could easily be collected and used in attacks against users of vulnerable versions.
- gnulinux 8y ago
  Did you even read the article? This is explained at length. Https doesn't give you that benefit since attacker can still single out package based on length and in https address is in plaintext.
debiandev 8y ago
HTTPS adds very little privacy in this context. The mirror IP address is in cleartext. Also, a smart observer might be able to detect APT traffic by analyzing the timing. If you want privacy, APT supports Tor and there are mirrors providing onion services: https://blog.torproject.org/debian-and-tor-services-available-onion-services https://blog.torproject.org/debian-and-tor-services-availabl...
- iheartpotatoes 8y ago
  I had no idea APT supports Tor, very cool! I don't think the OP knows that either.
  - gnulinux 8y ago
    Apt has supported HTTPS and tor since forever. Aws offers https mirror. OP is about defaults. If you want you can switch to https or tor or http.
alsadi 8y ago
Those arguments are invalid. Because debian/ubuntu fail to use https regimes like egypt/syria can track people who try install tor and they can cherry-pick block repos based on package name. I'm sorry for not liking your favorite color and distro. Please deal with it. And btw they don't digitally sign their package too (they sign separated meta data file having checksum which is not equivalent of embeding signature inside the package and validate it). Compare that to yum/rpm which use secure https and signed rpm and signed metadata (both the medium and the payload are secured)
- bnegreve 8y ago
  > Regimes like egypt/syria can track people who try install tor and they can cherry-pick block repos based on package name. They say https would not add privacy in this context because the package size (almost) uniquely determine the package name. Why is this invalid?
  - onion-soup 8y ago
    "Why do you need a speedometer when you can just calculate your current speed using tachometer, odometer and time, it's real simple man"
    - AstralStorm 8y ago
      It is. You want to download Tor in some hard to track way, you probably shouldn't use an easily trackable source. There are better options including getting sent an email and torrents. And given the scope of the attacker, fingerprinting by size and server is trivial so easily https adds nothing related to anonymity nor security.
    - bnegreve 8y ago
      Ok, fair enough.
  - rocqua 8y ago
    You can block based on a name because you see the name before the package is sent. You can't block based on package length, because you need to let the entire update through before you know the length. At that point, it's too late to block. Buffering the entire message doesn't work because TCP expects ACKs.
izzytcp 8y ago
GPG = Integrity/Safety | HTTPS = Confidentiality I want both, ppl who only want the first one are stupid. Those who don't do HTTPS are lazy and reckless, it's free & easy.
ctz 8y ago
The claims on this site are easily falsifiable by past bugs on debian's own bug tracker: eg https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710229 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710229 I've personally experienced this too: using apt in the presence of a captive portal replaces random bits of `/var/cache/apt` with HTML pages, breaking future updates until you manually find and fix the problem yourself.
- pascal_cuoq 8y ago
  The reverse argument also works: using HTTPS may lead you to link and expose, say, OpenSSL where you otherwise would not have needed to. OpenSSL has had dozens of vulnerabilities in the past: https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/news/vulnerabilities.html Some of these vulnerabilities have the potential for arbitrary code execution, leaving you worse off than the simpler solution based on the verification of cryptographic signatures that has fewer vulnerabilities by virtue of doing less. The discussion at https://whydoesaptnotusehttps.com https://whydoesaptnotusehttps.com is about the protocol. You can add implementation bug risks to the discussion if you want, but then include the risks from both the approaches being discussed.
  - zamadatix 8y ago
    You've proposed a reverse argument to an argument that was never made. ctz never said anything about vulnerabilities or implementation issues, they said a captive portal is a problem for apt over HTTP but not HTTPS. This is also true of ISPs that like to insert things into HTTP sessions.
    - pascal_cuoq 8y ago
      “bugs”
scoot_718 8y ago
Finding out the packages based on file sizes? Nope - https would hide the sizes of individual files within the entire session.
- rocqua 8y ago
  Timing alone would go a long way.
- gnulinux 8y ago
  Attacker can simply count the bytes. They can buffer one packet, send ack, and reject it based on bytes transferred. Also it's trivial know when next package starts. Apt doesn't steam all packages at once, it first send first package with http keep alive then waits until client orders the second package.
flyGuyOnTheSly 8y 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[2]. HTTPS would therefore only be useful for downloading from a server that also offers other packages of similar or identical size. That seems like a false dilemma imho. What's preventing APT from splitting up downloads into identically sized chunks of say 4kb?
deleted 8y ago
[deleted]
dpcx 8y ago
I think https by default would be a wonderful addition. I understand the complexities from the project's perspective. I understand the users wants for privacy. If the project not defaulting to https is that much of a privacy issue for you, set up a local mirror then point your boxes to that. Yes, someone could potentially still snoop your local network. But if they can do that, you've got bigger issues to worry about than the fact that they can see what packages you're installing. https://www.debian.org/mirror/ftpmirror https://www.debian.org/mirror/ftpmirror
lorenzhs 8y ago
Apparently Windows Update uses TLS without encryption (null cipher) which still provides integrity and authentication: https://twitter.com/swiftonsecurity/status/745333018697469953 https://twitter.com/swiftonsecurity/status/74533301869746995.... Debian's signing achieves the same result by signing the package list containing the packages' hashes with a known key.
- da_chicken 8y ago
  As far as I'm aware, all Windows Update packages are also digitally signed.
rocqua 8y ago
Besides the privacy issue of sending package names clear-text, there is a second non-mitigated issue: Censorship. An MitM could selectively block certain package being installed / update. Imagine using this to prevent: Bitcoin being installed / enforce a ban on crypto without backdoors / block torrent installations. This doesn't work as well with the 'recognize package size' method because you need to download the entire package before you know the size. Given the need for Ack in TCP, an MitM can't just buffer data until they have the entire package size.
- loeg 8y ago
  > This doesn't work as well with the 'recognize package size' method because you need to download the entire package before you know the size. Given the need for Ack in TCP, an MitM can't just buffer data until they have the entire package size. All they have to do is corrupt the final packet and the package checksum fails. An attacker only needs to buffer a single packet worth of data.
hyperpape 8y ago
One reason to prefer HTTPS is that in the event of a vulnerability in the client code, an attacker cannot trigger that vulnerability using a MITM attack if HTTPS is in use. One such vulnerability was recently found in apk-tools: https://nvd.nist.gov/vuln/detail/CVE-2018-1000849 https://nvd.nist.gov/vuln/detail/CVE-2018-1000849
- Klathmon 8y ago
  While I agree with your point, a counterpoint is that vulnerabilities in the HTTPS implementation are also possible, and by introducing HTTPS code you are increasing the surface area of possible vulnerabilities.
  - andy_ppp 8y ago
    How is this making you more vulnerable that not having it? It’s like saying don’t bother having locks on your doors because they are subject to picking... not a great argument.
    - hyperpape 8y ago
      This isn't accurate. If the SSL code incorrectly trusts the wrong server, then you're no better off but also no worse off. If the code has a RCE vulnerability caused by bad parsing logic, then you're worse off than you would be without it. My counter-counterpoint is that while OpenSSL had (has?) horrible security issues, it's still worth using HTTPS in principle, because a modern internet connected system that has no trustworthy SSL library is going never not going to have security problems. Whether it's hardening OpenSSL, shipping BoringSSL, or anything else, systems just have to get this right, and once they do, applications like apt can take advantage of it.
      - AstralStorm 8y ago
        Problem being that such broken system might especially want to peruse package updates...
    - 8y ago
dooglius 8y ago
>To mitigate this problem, APT archives includes a timestamp after which all the files are considered stale How often is this, practically? If I'm understanding this right, each new timestamp would come only with a package upgrade, meaning the time period is quite a long time indeed, long enough for a replay attack to work. I would argue that there should be a mechanism requiring a signed the-latest-package-is-X message updated at least every day or so. Edit: it looks like this is actually what's going on. The page wasn't clear, but it is a metadata "Releases" file that is timestamped, not the packages themselves.
- jkaplowitz 8y ago
  The security repository generally serves up a field in its metadata saying that the data shouldn't be trusted for more than 7 days, if it hasn't changed since 2014 when I encountered this duration as part of my day-job work. It's safe to assume the trusted duration hasn't increased, at least.
  - dooglius 8y ago
    http://security-cdn.debian.org/dists/stable/updates/Release http://security-cdn.debian.org/dists/stable/updates/Release is 10 days in the future. I still think it should be shorter, as it's pretty conceivable to exploit a 1-day vulnerability in that timeframe, but it's not that bad.
3pt14159 8y ago
This argument boils down to two things: One side: We want performance / caching! Other side: We want security! Both sides sometimes argue disingenuously. It's true that caching is harder with layered HTTPS and that performance is worse. It's also true that layering encryption is more secure. (It's what the NSA and CIA do. You smarter than them?) Personally, I'd default to security because I'm a software dev. If I were a little kid on a shoddy, expensive third world internet connection I'd probably prefer the opposite. I just wish it were up to me.
- eloisant 8y ago
  Not in this case, just read the tl;dr in the article (you don't even need to read the whole article).
- buster 8y ago
  Except that this page argues, that you are not increasing security in this case.
  - zeroimpl 8y ago
    But it does, because HTTPS can ensure you always get up to date data. They have a solution involving timestamps for HTTP, but that is still clearly less secure than the guarantee from HTTPS.
  - shittyadmin 8y ago
    This page is wrong, for example they claim there's no privacy increase here but quite clearly there's a huge difference between an attacker being able to tell "you're downloading updates" and an attacker being able to tell "you're downloading version X.Y of Z package" - worse, that information could actually later be used to attack you based on the fact that the attacker now knows what version to find vulnerabilities in, including non-exposed client software for email, documents, browsers, etc. It's a relatively insignificant security benefit for most, but could prove an important one for those who targeted attacks are used against.
    - 8y ago
lifthrasiir 8y ago
We like to talk about, say, the compromise of integrity and/or authenticity, information leak and so on, but they are not only things TLS/HTTPS was prepared for. Indeed, it is often overlooked that we have two kinds of exploitations in this space. I tend to label them as "active" and "passive". One of the best known passive exploitations is a JavaScript injection from ISP---Comcast did it in 2017 [1] for example. They alone are typically harmless or annoying at best, but they are indicative of the real security problem lurking around, and often can evolve into active exploitations. It might be probably true that APT is a simple service that does not require the full TLS capability. But APT is only prepared for active exploitations. Passive exploitations will effectively compromise the availability, by compromising the integrity in the relatively predictable way. I don't think APT is also prepared for passive exploitations---casual users will be much more prone to them. [1] https://forums.xfinity.com/t5/Customer-Service/Are-you-aware/td-p/3009551 https://forums.xfinity.com/t5/Customer-Service/Are-you-aware...
jdfellow 8y ago
My corporate network used a transparent https man-in-the-middle proxy. That is, transparent as long as you're using a Windows machine that has been configured by the help desk and using applications that utilize the Windows certificate store, which doesn't include git, pip, or npm. If pip or npm used gpg signing of packages rather than https, this wouldn't be a big deal. But as it stands, it's a nightmare on various Windows systems, Linux boxen, and Docker images to get the code you need.
crankylinuxuser 8y ago
There's also a current and ongoing "discussion" (I say pejoratively) regarding the same issue with VideoLAN. They can't (easily) use HTTPS because they don't control the mirrors. However the package download/update itself is also signed with GPG, thus guaranteeing tamper resistance. https://twitter.com/videolan/status/1086672630994927616 https://twitter.com/videolan/status/1086672630994927616
allan_ 8y ago
nothing justifies debian making you `apt-get install apt-transport-https` over `http` before you can add your own repos which are https only of course. but hey, it's debian.
adenner 8y ago
another option for a "secure" connection is to use the apt onion services from tor https://blog.torproject.org/tor-heart-apt-transport-tor-and-debian-onions https://blog.torproject.org/tor-heart-apt-transport-tor-and-...
sgjohnson 8y ago
There are benefits in switching to HTTPS even if it's not done for security reasons. Namely, HTTP/2. However, I'm not sure if the benefit in speed would be measurable for apt.
- toast0 8y ago
  HTTP/2 is more likely to be a downside than an upside for apt. You would have additional framing overhead, and I can't see a benefit over pipelined http/1.1 be (which is definitely doable because all the requests are get for static files). Maybe header compression of the small headers could be a very minor win. Multiplexing within a tcp stream is at best neutral for this case, but probably negative: on the client side, it means the possibility of multiple partial files instead of one; on the server, it means more parallel demand on the file system.
- anfilt 8y ago
  How is HTTP/2 a benefit for a file store? The design of HTTP/2 helps websites more. It supports push since webpages include resources that a server knows a client is going to need anyways. This avoids request latency for websites. It also allows connection reuse (via multiplexing. However, again this is mostly helpful for websites. Decrease latency by avoiding tcp hand shake. It allows for slightly smaller headers since it's a binary protocol. However, pretty much none these really help with large file downloads, and other use cases like APT. Even the headers will be dwarfed by the files themselves, and the header information is probably already pretty minimal. Also HTTP/2 does not require TLS it's just pretty much all the browsers ignore that the standard does not require TLS. However, they are trying to push for more encrypted traffic. A decision I don't really think browsers should be making.
hannob 8y ago
I guess I can copy over a comment I made when this previously made rounds: I have a few problems with this. The short summary of these claims is “APT checks signatures, therefore downloads for APT don’t need to be HTTPS”. The whole argument relies on the idea that APT is the only client that will ever download content from these hosts. This is however not true. Packages can be manually downloaded from packages.debian.org and they reference the same insecure mirrors. At the very least Debian should make sure that there are a few HTTPS mirrors that they use for the direct download links. Furthermore Debian also provides ISO downloads over the same HTTP mirrors, which are also not automatically checked. While they can theoretically be checked with PGP signatures it is wishful thinking to assume everyone will do that. Finally the chapter about CAs and TLS is - sorry - baseless fearmongering. Yeah, there are problems with CAs, but deducing from that that “HTTPS provides little-to-no protection against a targeted attack on your distribution’s mirror network” is, to put it mildly, nonsense. Compromising a CA is not trivial and due to CT it’s almost certain that such an attempt will be uncovered later. The CA ecosystem has improved a lot in recent years, please update your views accordingly.
- xcaaa 8y ago
  How is it not trivial if rogue organizations like "Staat der Nederlanden" have default certificates in the browser? Hint: The Netherlands is world leader in surveillance of its own citizens and inhabitants.
  - vegardx 8y ago
    Because they would be caught doing it very quickly. There are so many ways to detect this.
    - shittyadmin 8y ago
      And ultimately none of those ways to detect this aren't useful against a sufficiently targeted attack with direct access to the signing key. It's one thing if you sign a bad key for Google.com, publish it in CT logs and then put it up on the public internet - it's quite another if you sign a bad key for midsizecompany.com, keep it out of the CT system and use it only in a targeted attack against non-technical individuals who are unlikely to examine a certificate or use things like Certificate Watch. With that said, I still believe serving it over HTTPS would be a substantial improvement. Perhaps pin the cert or at least the CA out of the box to prevent such attacks.
lreeves 8y ago
Yeesh, as someone who has had to troubleshoot more than a few times HTTP payloads that were mangled by shitty ISP software to inject ads or notifications I would love HTTPS as a default to prevent tampering. I get the arguments against it, but I have 100% seen Rogers in Canada fuck up HTTP payloads regardless of MIME types while rolling out "helpful" bandwidth notifications. Signatures will tell you yes this is corrupt but end-to-end encryption means that the person in the middle can't even try.
- fyjvd90 8y ago
  Likewise, integrity of the download is the primary reason I’ve switched downloads to HTTPS too. The argument that singed downloads is enough fails to address what the user is supposed to do after the integrity has failed? A redownload can result in the same tampered with file. This isn’t hypothetical btw, it happens in the real world, I’ve had ISPs in Ireland and South Africa damage downloads due to their injections and users don’t care if it’s their ISP, they get pissed off at you unfortunately.
TedLePoireau 8y ago
The "Date, Valid-Until" timestamp mitigates replay-attack, cool. But what if a vulnerability is discovered in a package and an MITM attack prevent you from downloading the new patched version, making you believe your system is up to date although it's not ?
- AstralStorm 8y ago
  No, apt then shows a message about failing to download fresh update lists. For security repo, the period it's 10 days.
jopsen 8y ago
Lots of reasons to use HTTPS most notable is defense-in-depth. A good design always aims to have multiple othorgonal security mechanisms in place.
jen20 8y ago
I'm somewhat surprised that no-one has (yet) linked to this post [1] by Joe Damato of Packagecloud, which digs into attacks against GPG signed APT repos, or the paper which initially published them [2]. The post makes clear in the third paragraph: "The easiest way to prevent the attacks covered below is to always serve your APT repository over TLS; no exceptions." [1]: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/ https://blog.packagecloud.io/eng/2018/02/21/attacks-against-... [2]: https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.p...
- fucking_tragedy 8y ago
  Thanks for posting these, I was unaware that they even existed.
ktrask 8y ago
At a research institute I worked for, we had a proxy server that intercepted http. The antivirus software on the proxy made it impossible to download some security updates once in a while. Fortunately it was possible to change the ubuntu URIs to https:// https:// to use HTTPS and the broken antivirus sofwate did not intervene anymore.
boxingdog 8y ago
well, this is like saying your car does not need airbags because it already has brakes and your gonna die anyway
jancsika 8y ago
I bet there are many FLOSS advocates who don't read that page as being the result of a cost-benefit analysis. They read it as an inspiring story of the rebels winning one against the https Empire. Because I never see the caveat wrt apt that, "of course, we are a super edgy edge-case that should not be used as a model to rationalize a knee-jerk refusal to use SSL for common cases." I say this because I've corresponded with such advocates about a completely common case for SSL-- setting up a LetsEncrypt certicate, say. The response I often get doesn't make any sense unless I assume they read a page like this and remembered the feels while forgetting all the relevant details that separate apt from their common case.
kerng 8y ago
Using https is a basic security principle - not using it means you are doing security wrong and someone will be bitten by it. They can argue and justify why they do it as much as they want, that actually shows a bit of security immaturity on their side.
gnode 8y ago
Layering HTTPS on top of the existing authentication system adds the obvious benefit of confidential communication, such that an eavesdropper can't see what packages you're downloading. There's an argument that you can infer the package from the size of download, but this is defeated by downloading partial regular sized chunks of the file with some overlap to mask the actual size. The only sensible argument against HTTPS seems to be infrastructure cost. This made more sense in the past, but nowadays hardware crypto acceleration (e.g. AES-NI) is commonplace, and certificates can be obtained for free. Ultimately it's up to mirrors to decide if they're willing to provide HTTPS.
alexnewman 8y ago
Every other vendor, uses https and also signs packages. Clearly they are all wrong and apt is the only correct one.
deleted 8y ago
[deleted]
throw2016 8y ago
Beware of strangers bearing gifts. There is a lot of https scaremongering from a certain subset of people with objectives one finds difficult to understand. If they were genuinely concerned about privacy, security and surveillance they would have a lot to say about the out of control surveillance economy and its participants including their employers, the security model of browsers, mobile operations systems, javascript, systemic user stalking and hoovering up data. Yet those stories are mainly driven by people outside the tech ecosystem and within there is mostly silence interspersed with vague economic justifications so there is something truly bizarre about https extremism on the grounds of privacy. If your packages are already signed why do you need a middleman? That is a better trust model for a distributed Internet than a centralized CA that is not accountable to individuals and can be compromised by power. Here people are neck deep in business models stalking people online 24/7 and tracking their location and some are 'concerned' about protecting the list of packages you download?
- 0xdeadbeefbabe 8y ago
  > Here people are neck deep in business models stalking people online 24/7 and tracking their location and some are 'concerned' about protecting the list of packages you download? That's believable. "There are a thousand hacking at the branches of evil to one who is striking at the root." - Henry David Thoreau. Nice word "hacking". Edit: Uh oh maybe Thoreau was pro CA.
l0b0 8y ago
So they don't consider privacy beyond which host I contact, which is weird, because I'm pretty sure which version of packages I have is relevant to an attacker. And in case of a zero-day exploit it would be really handy not having to wait for some global timeout during which I won't see any updates.
amelius 8y ago
Question: does APT work with HTTP proxies, which e.g. some company networks impose as the only means of internet connectivity?
guardiangod 8y ago
As an exploit analyst currently focusing on network traffic, can we stop all this fascination with SSL/TLS? TLS is incredible, but let's use the right tool for the job. Contrary to Let's Encrypt motto, applying TLS to _everything_ can be bad for security. Let's Encrypt, when are you going to revoke placeimg.com's certificate? The site has been pushing Exploit Kit's malicious payloads since Jan 18 2019 via SSL. Many Flash/IE users are getting infected because most firewalls are unable to peer into SSL tunnels signed by you. (To be fair, Let's Encrypt is not the only cert authority getting abused (Comodo, yes you))
josteink 8y ago
With HTTPS, I need to trust every government in the world to not interfere with CAs. With GPG, I only need to trust Debian to give me Debian. Is there really a question about security here?
forty 8y ago
I wish APT used HTTPS if only to be able to tell my proxy "only allow HTTPS" and never have to worry about unencrypted traffic ever. Currently it's the only HTTP trafic my server are generating. Plus it's polluting my proxy logs as instead of having only the domain as it's the case for all the other log, I have the full URLs :)
jopsen 8y ago
> providing a huge worldwide mirror network available over SSL is not only a complicated engineering task Nobody said each mirror couldn't have its own certificate and its own domain. The host names of these mirrors are usually obtained from a trusted source. HTTPS in addition to GPG signatures does no harm. It also means that one would have to compromise two entities, my distro's GPG key and my mirror's certificate.
Rapzid 8y ago
> HTTPS does not provide meaningful privacy for obtaining packages. That's a very subjective and circumstantial statement being passed off as fact. Just because one can list a few scenarios where HTTPS wouldn't prevent a malicious actor from achieving their goals, doesn't mean HTTPS does not increase security/privacy for apt in other situations. Further, in certain contexts, guessing and proving are not fungible.
alexnewman 8y ago
I guess that explains why I have install ca-certificates, and ubuntu doesn't ship with them.
furiousindexer 8y ago
I am seeing quite a bit of misinformation about how package managers work so I'd love to share what I have learned. I work with index files on a daily basis, and we might possibly generate more index files than any other organization on the planet. Here is my chance to share some of this knowledge! TLDR/Summary We can trust the Release file because it was signed by Ubuntu. We can trust the Packages file because it has the correct size and checksum found in the Release file. We can trust the package we just downloaded because it is referenced in the Packages file, which is referenced in the Release file, which is signed by Ubuntu. Some basic package manager principles I work with APK, DEB, and RPM based package managers and each of them behave very similar. Each repository has a top level file, signed by the repository's maintainer, that includes a list of files found in the repository and their checksums. When your package manager does an update, it looks for this top level file. For DEB based systems, this is the Release file For APK based systems, this is the APKINDEX.tar.gz file For RPM based systems, this is the repodata.xml file These files are all signed by the repository's gpg key. So the Release file found athttp://us.archive.ubuntu.com/ubuntu/dists/bionic/Release http://us.archive.ubuntu.com/ubuntu/dists/bionic/Release and is signed by Ubuntu and the gpg key is included in your distribution. Let's hope Ubuntu doesn't let their gpg key into the wild. Assuming that Ubuntu's gpg key is safe, this means that the system can verify that the Release file did in fact come from Ubuntu. If you are interested, you can click on the previous link, or navigate to Ubuntu's repository and open up one of their Release files. Release file In the Release file you'll see a list of files and their checksum. Example:55f3fa01bf4513da9f810307b51d612a 6214952 main/binary-amd64/Packages 9f666ceefac581815e5f3add8b30d3b9 1343916 main/binary-amd64/Packages.gz 706fccb10e613153dc61a1b997685afc 96 main/binary-amd64/Release 9eae32e7c5450794889f9c3272587f5e 1019132 main/binary-amd64/Packages.xz 5dd0ca3d1cbce6d2a74fcc3e1634ac12 96 main/binary-arm64/Release The left column is the checksum, then the size of the file, and lastly the location of the file. So we can download the files referenced in the Release file and check them for the correct size and checksum. The Packages or Packages.gz file is the one we care about in this example. It contains information about the packages available to the package manager (apt in this case but again, almost all of the package managers behave very similar). Packages file Since we know that we can trust the Release file (because we have proven it was signed by Ubuntu's gpg key), we can then proceed to download the contents of the Release file. Let's look at the Packages file specifically as it contains a list of packages, their size, and checksum. Filename: pool/main/a/accountsservice/accountsservice_0.6.45-1ubuntu1_amd64.deb Size: 62000 MD5sum: c2cffd1eb66b6392f350b474e583adba SHA1: 71d89bd380a465397b42ea3031afa53eaf91661a SHA256: d0b11d1d27fe425bc91ea51fab74ad45e428753796f0392e446e8b2450293255 The Packages file includes a list of packages with information about where the file can be found, the size of the file, and various checksums of the file. If you download a file through commands like apt install and any of these fields are incorrect, apt will throw an error and not add it to the apt database. It's time to debunk some myths! Can an attacker send me a fake Release file? Sure, but apt will throw it out because it's not signed by Ubuntu (or whoever your repository maintainer is like centos, rhel, alpine, etc) Can an attacker send me an old index from an earlier date that was signed by Ubuntu that has old packages in it with known exploits? Sure, but apt will throw it out because it will have a date (in the Release file) that is older than what is stored in the apt database. For example, the current bionic main Release file has this date in it: Date: Thu, 26 Apr 2018 23:37:48 UTC So if you supply it with a Release file older than that timestamp, it will throw it out because it is older than what it currently knows about. I hope this helps clear the air! Shameless plug. If you are serious about security and not just compliance, check out our Polymorphic Linux repositories. https://polyverse.io/ https://polyverse.io/ We provide "scrambled" or "polymorphic" repositories for Alpine, Centos, Fedora, RHEL, and Ubuntu. We use the original source packages provided in the official repositories and build the packages but with memory locations in different places and ROP chains broken. Installation Installation is a one line command that installs our repository in your sources.list or repo file. There is no agent or running process installed. It is literally just adding our repository to your installation. The next time you do an `apt install httpd` or `yum install docker` you'll get a polymorphic version of the package from our repository. You can see it in action in your browser with our demo: https://polyverse.io/learn/ https://polyverse.io/learn/ What does it do? Many of the replies in this post referenced an attacker tricking a server into an older version of a package that has a known exploit. We stop this. Even if you are running an old version of a package, with a known exploit, memory based attacks will not work on the scrambled package because the ROP chain has been broken or as we call it "scrambled". So with our packages, you can run older versions of a package and not be effected by the known exploits. This also means that you are protected from zero day attacks just by having our version of the package. FREE! For individuals and open source organizations you can use our repositories for free. I hope you try it out!
sepent 8y ago
"HTTPS does not provide meaningful privacy for obtaining packages. As an eavesdropper can usually see which hosts you are contacting, if you connect to your distribution's mirror network it would be fairly obvious that you are downloading updates." It is a dangerous mistake to decide what kind of privacy people need. Privacy should be absolute and without conditions. What if you live in Iran? Some Ubuntu packages are already inaccessible due to government's pornography keywords censorship. E.g. I can't download "libjs-hooker" from this http link http://archive.ubuntu.com/ubuntu/pool/universe/n/node-hooker/libjs-hooker_0.2.3-1_all.deb http://archive.ubuntu.com/ubuntu/pool/universe/n/node-hooker... from Iran. What if the government decides to censor the "tor" package?
isostatic 8y ago
https://usn.ubuntu.com/3863-1/ https://usn.ubuntu.com/3863-1/ "Max Justicz discovered that APT incorrectly handled certain parameters during redirects. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could potentially be used to install altered packages." Far easier to do a MITM attack when apt isn't using https by default Security is best in layers
jwilk 8y ago
Previous discussion: https://news.ycombinator.com/item?id=16221563 https://news.ycombinator.com/item?id=16221563

515 points by rishabhd 8y ago

Even though the packages are signed cryptographically, there are possible risks when using an unencrypted connection. A man-in-the-middle attack could simply work by serving you a signed, but outdated packages list, preventing your distribution from updating and leaving you vulnerable to security holes. It's the same attack an evil mirror could do as well. So if you want to be really sure you should probably use two independent mirrors over an HTTPS connection.

niea_11 8y ago
The website mentions this towards the end (Replay attacks) : To mitigate this problem, APT archives includes a timestamp after which all the files are considered stale The time stamp is described here[1], but it is not clear how the expiration date is decided. 1: https://wiki.debian.org/DebianRepository/Format#Date.2C_Valid-Until https://wiki.debian.org/DebianRepository/Format#Date.2C_Vali...
- julian-klode 8y ago
  Well, defining the expiration date is up to the server. Debian picks a week. Ubuntu does not use it, I have started a launchpad branch last year, but um, I don't know launchpad, so it might take some more years ;)
philjohn 8y ago
They cover this - timestamps are embedded in the packages, and also signed. If they're too old it won't update and you'll know something is amiss.
- na412 8y ago
  More precisely, an expiration timestamp is embedded in the repository metadata. Packages in debian and derivatives are not signed. Instead, the manifest that lists all the available packages and their checksums is signed. That's also where the expiration data is stored.
  - JdeBP 8y ago
    Even more precisely still, not even the lists of packages are signed. Only InRelease and Release are signed, and they only contain the list of Package files. It's FreeBSD that has the approach of just one signed file containing everything. APT has moved closer to it over the years, but it is not there yet. * https://unix.stackexchange.com/a/332441/5132 https://unix.stackexchange.com/a/332441/5132

mjevans 8y ago

It doesn't need to, the actual security is implemented on a per-package basis. https://wiki.debian.org/SecureApt#How_to_manually_check_for_package.27s_integrity https://wiki.debian.org/SecureApt#How_to_manually_check_for_...

Tepix 8y ago
You may not want to make it too easy to find out which packages you have installed.

dvfjsdhgfv 8y ago

I feel the HTTPS hysteria is going too far. For some strange reason people started to consider it a security panacea, without often understanding its limitations. Accusations against APT are a perfect example (it's built-in security mechanisms are superior to what HTTPS has to offer).

Ensorceled 8y ago
That’s like saying I don’t need a helmet because I have all of this body armour. At a minimum, HTTPS prevents leakage of information about your configuration but there are several direct attack vectors listed in other threads. Please stop calling it “hysteria”.
- dvfjsdhgfv 8y ago
  > Please stop calling it “hysteria”. From https://www.beauzee.fr/2017/07/04/videolan-and-https/ https://www.beauzee.fr/2017/07/04/videolan-and-https/: > If you use homosexuality in order to insult/make fun of someone, it is homophobic. You might disagree, but that’s irrelevant. It is. Calling members of the projet on their personal phones and insulting them is probably a bit of an overreaction, don’t you think?
chii 8y ago
Secure against modification, is not the same as secure against information leakage and privacy. Using a non-encrypted connection means that it's trivial to work out what packages you download. Using a secure connection at least makes it 1 step harder to infer that information. However, whether packages should be kept private is all-together another question. I argue that OS updates and packages related to that do not need to be kept private, but applications packages do.
- dvfjsdhgfv 8y ago
  > Using a non-encrypted connection means that it's trivial to work out what packages you download. Using a secure connection at least makes it 1 step harder to infer that information. It is trivial still in the case of APT. That's exactly my point: people start believing HTTPS will protect them against many attack vectors it doesn't. That's OK for uninformed people to believe in the magic of a padlock in the address bar, but technical folks should really know better. If I have access to your network traffic and intend to see which packages you download by apt, I will do it irrespective of whether you use HTTPS or not.

SparklingCotton 8y ago

These reasons make no sense. - SSL certs are hilariously simple with Let's encrypt. - Pretending privacy is a non-issue by saying SSL has the same is stupid, and is it even true with pipelining and HTTP/2 ? Also this excuse conflates the transport layer security with the upper protocols! - "False sense of security". FFS! This excuse could be used for basically ALL SSL protected services, like Ycombinator or Facebook! I thought Debian developers' brains would be bigger than this.

sschueller 8y ago
Let's encrypt is also "hilariously" centralised. What do you do if Let's encrypt is blocked in your country or they refuse to issue you a certificate because of US sanctions?
- lolc 8y ago
  Block Let's Encrypt? How would that even work? They'd have to block all addresses where the webserver uses Let's Encrypt certificates. Or MITM your SSL connections. If Let's Encrypt is blocked, you're not getting the full Internet. Complain with your ISP or government if they do that! If Let's Encrypt refuses to cert your domains, got to another provider. They're not the only one.
  - amaccuish 8y ago
    > They'd have to block all addresses where the webserver uses Let's Encrypt certificates. They're talking about blocking access to letsencrypt servers, which would prevent you from getting a certificate.
    - lolc 8y ago
      Oh. That exists? I still don't see how that would be a problem Debian should consider in their considertions around SSL. After all, if your server's upstream is blocks access to Let's Encrypt servers, why are you trying to operate an official Debian mirror there? What's the point of having a Debian mirror connected to such a shitty upstream?

TorKlingberg 8y ago

The arguments are correct. APT does not need HTTPS to be secure. That said, if APT was designed today I'm sure it would use HTTPS. It's now the default things to do, and Let's Encrypt makes it free and easy. However Debian, where APT is from, relies on the goodwill of various universities and companies to host their packages for free. I can see that they don't want to make demands on a service they get for free, when HTTPS isn't even necessary for the use case. Also since APT and Debian was created in the pre-universal HTTPS days, it does things like map something.debian.org to various mirrors owned by different parties. That makes certificate handling complicated.

stefan_ 8y ago
Why would it? As the site lays out, HTTPS is strictly inferior to the scheme used by APT. You can not get more security by adding a less secure mechanism to a better one. It's not additive.
- julian-klode 8y ago
  Of course you'd get more security. Analogy: It's like your hanging on a rope and also add a safety net. If the rope breaks, you only fall on the safety net instead of the ground. All software has bugs, so if you add two buggy security solutions, you might only be able to exploit a bug in one, but the other still gives you the safety.
  - kiallmacinnes 8y ago
    That's not always true though, and it can be really hard to tell if a particular combination is going to make things better or worse. e.g. the "Breach" HTTPS+Compression vulnerability. To continue your analogy: The rope gets tangled in the safety net, forcing you to jump or proceed up with a loose rope, because you can no longer move the rope..
  - marcosdumay 8y ago
    This is not the physical world. Digital security strength is measured on orders of magnitude, and two mechanisms providing security with very different orders of magnitude do not add in any practical sense.

mgliwka 8y ago

>This can lead to a replay attack where an attacker substitutes an archive with an earlier—unmodified—version of the archive. This would prevent APT from noticing new security updates which they could then exploit. >To mitigate this problem, APT archives includes a timestamp after which all the files are considered stale[4]. Let's take a look at the repo spec then: https://wiki.debian.org/DebianRepository/Format#Date.2C_Valid-Until https://wiki.debian.org/DebianRepository/Format#Date.2C_Vali... > The Valid-Until field may specify at which time the Release file should be considered expired by the client. Client behaviour on expired Release files is unspecified. “Should”, “may”, and unspecified behaviour.

cbhl 8y ago
Well, of course the client behavior is under-specified -- sometimes the client is a human constructing a URL to download a .deb in a web browser over a corp-approved proxy, and then hand-installing the package with `deb -i`, bypassing all the security checks. Or sometimes there's a caching proxy (or three) between the client and the server. Or maybe IT has modified apt to only connect to repositories maintained by the IT department, and rejects sources from other domains.

avar 8y 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" Is it really not difficult? I bet if you sorted all the ".deb" packages on a mirror by size a lot of them would have a similar or the same size, so you wouldn't be able to tell them apart based on the size of the dialog. Furthermore, when I update Debian I usually have to download some updates and N number of packages. I don't know if this is now done with a single keep-alive connection. If it is, then figuring out what combination of data was downloaded gets a lot harder. Finally, this out of hand dismisses a now trivial attack (just sniff URLs being downloaded with tcpdump) by pointing out that a much harder attack is theoretically possible by a really dedicated attacker. Now if you use Debian your local admin can see you're downloading Tux racer, but they're very unlikely to be dedicated enough to figure out from downloaded https sizes what package you retrieved.

ianbooker 8y 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" >> "Is it really not difficult? I bet if you sorted all the ".deb" packages on a mirror by size a lot of them would have a similar or the same size, so you wouldn't be able to tell them apart based on the size of the dialog." Human readable sizes: Sure. Byte size info: Not so much. And even if: Things would become very clear to the attacker after one update cycle for each package. If you really want to mitigate information about downloaded packages you would have to completely revamp apt to randomize package names and sizes, and also randomize read access on mirrors...
- shasheene 8y ago
  > If you really want to mitigate information about downloaded packages you would have to completely revamp apt to randomize package names and sizes, and also randomize read access on mirrors... There isn't a need to randomize package names, or randomize read access on the mirror, given fetching deb files from a remote HTTP apt repository is a series of GET requests. Randomizing order of these requests can be done completely on the client side. Package sizes are still problematic. Here's a suggestion: if each deb file was padded to nearest megabyte, and there was a handful of fixed-size files (say, 1MB, 10MB and 100MB), the apt-get client could request a suitably small number of the padding files with each download. This would improve privacy with a minimum of software changes and bandwidth wastage.

Theodores 8y ago

Do we now have a custom domain name on a per article basis? I find it strange to have a site that is just about one thing that is not that important to most people on a custom domain. If there were pages and pages of information then yes this might make sense but there isn't. Coming soon... howtotieyourownshoelaces.com The premise of this article per domain reminds me of 1998 when everyone thought that instead of search engines people would be typing in URLs, e.g. 'yescupofteaplease.com' so URLs like 'pets.com' were seen as goldmines-to-be.

JdeBP 8y ago
Enjoy http://islinuxaboutchoice.com/ http://islinuxaboutchoice.com/ and http://heartbleed.com/ http://heartbleed.com/ . (-:
dooglius 8y ago
I see it as more akin to a vanity plate; no one expects it to be functionally useful, but it's something people will see and so it is somewhat decorative to put something there.

feikname 8y ago

Even though replay attacks will be of no use after some time, one could MITM during the vulnerable timeframe to prevent a critical (0day) security update from happening and therefore gaining control over the system, so if you're specially targetable, I believe it's totally worth switching to an HTTPS mirror instead. Other than that, most should be safe ig. One annoying thing is that the page name is misleading. apt does use/support https, it's just that Debian chooses for its default mirrors to it be optional.

j16sdiz 8y ago
If the attacker can MITM you, he can block your access too.
- feikname 8y ago
  Blocking your access is very noticeable, not having one package upgrade is not.

nurettin 8y ago

reminds me of this http://n-gate.com/software/2017/07/12/0/ http://n-gate.com/software/2017/07/12/0/

giancarlostoro 8y ago

Another scary thing is that despite not including it, when you do have a need for it you're advised to install apt-transport-https[0]. I can't remember the specific package that requires me to go this route, but it always reminds me "oh they're not using https", I'm surprised they don't pull over SSH or something, doesn't git work with SSH as well? [0]: https://packages.debian.org/sid/apt-transport-https https://packages.debian.org/sid/apt-transport-https Edit: It was VSCode: https://code.visualstudio.com/docs/setup/linux https://code.visualstudio.com/docs/setup/linux So Microsoft provides apt packages over https, but Debian doesn't.

chungy 8y ago
> So Microsoft provides apt packages over https, but Debian doesn't. See https://deb.debian.org/ https://deb.debian.org/ -- it works just fine. HTTPS might prevent some kind of surveillance, entities (ISPs, governments, any other MITMs) from determining what kind of packages you're installing, and this might be beneficial, but plain old unencrypted HTTP is often faster if these aren't a big concern (they likely aren't in most developed nations and for most occupations). Lack of encryption overhead as well as transparent proxies being able to serve files are huge boons to this.
- dTal 8y ago
  The article points out that HTTPS offers almost no protection against this kind of surveillance, since packages are almost uniquely identifiable by size.
  - zaarn 8y ago
    With HTTPS you would be able to use HTTP/2 which means you can multiplex a single connection and once you download more than 2 packages, identifying which you installed is impossible. With plain HTTP it remains possible no matter how much pipelining you do.
    - icebraining 8y ago

pksadiq 8y ago

APT many not be using HTTPS. But APT does support HTTPS builtin since version 1.5. I couldn't find any changelog or NEWS for that, but https://packages.debian.org/sid/apt-transport-https https://packages.debian.org/sid/apt-transport-https says so. I myself uses HTTPS mirror provided by Amazon aws (https://cdn-aws.deb.debian.org/ https://cdn-aws.deb.debian.org/). I do so because My ISP sometimes forward to it's login page when I browse HTTP URLs. Also, it does sometime include Ads (Yeah, it's really bad, but it does remind me that I'm being watched).

RidingPegasus 8y ago
I watched this blow up on infosec twitter and it made no sense, APT has https or even Tor if you really insist on it. Takes 30 seconds to configure. Storm in a teacup.
- yrf 8y ago
  infosec twitter is crap like any other twitter subculture, full of drama queens and clickbait to increase their fav/rt count. What's even sadder is that they make no money off it.
  - eqqn 8y ago
    Indeed, something similar happened just last week. theHacker News(not to be confused with HN) twitter lashed out at VLC for not updating over https, which essentially uses same(ish?) code signing as described by APT. A bit of a shit show.
    - deleted 8y ago
      [deleted]
    - detaro 8y ago
      HN also had a big thread participating in the fray... I'm seriously tempted to start flagging links that point to "bad"/"outrage" bugtracker decisions like this, wide public distribution seems to make things quite a bit worse.

gralx 8y ago

https://onion.debian.org/ https://onion.debian.org/ Scroll to the end for a very simple how-to.

kiallmacinnes 8y ago

One thing that wasn't touched on - the mirror network. There are 100's of mirrors for all the major distros ran by third parties, if e.g. Debian wanted apt over HTTPS, they would need to hand out a debian.org SSL cert+key to all of them. (And convince them all to take the CPU overhead hit of TLS) EDIT: Since I can't reply to all the downvoters, I'll add here.. LetsEncrypt does not solve this. http://us.archive.ubuntu.com/ http://us.archive.ubuntu.com/ - that goes to likely 10's of different mirrors. Which one will the LetsEncrypt verification call hit?

majewsky 8y ago
So? In the age of Let's Encrypt, this task is (or rather, should be) downright trivial. Source: Using multiple dozens of LE-issued certs without even thinking about it.
zaarn 8y ago
What? No. The mirrors would just need to install a letsencrypt-compatible client and setup SSL via that. On any modern CPU since 2011 or so, TLS overhead is below a percent and a decent cheap dedicated box should be able to saturate a 1 Gbps uplink.
- toast0 8y ago
  Actually, no, the mirrors may not be able to verify themselves with let's encrypt. A hostname like ftp.us.debian.org resolves to many different mirrors, and may not resolve consistently around the world -- if that's the case, let's encrypt will not be able to verify the hosts through http challenges. Also, 1gbps is pretty small. I can't find any documentation on traffic, but I'd imagine mirrors in popular places are at least on 10gig.
  - zaarn 8y ago
    I have a 10Gbps uplink on my personal server and I can easily saturate it without getting capped on CPU or RAM. LE offers other challenges to verify hosts, like DNS verification. DNS verification can be done easily with an external API for mirror owners to hit (most ACME clients offer DNS challenge with the standard update protocol for DNS which can be secure appropriately).

BetaCygni 8y ago

I don't care for home-brew security, I need something standard. Also... the firewall at work breaks APT HTTP pipelining. Very very annoying. It would not be able to do so if APT was using HTTPS.

kiallmacinnes 8y ago
The signature method used by Linux mirrors has existed longer than HTTPS has, there's nothing homebrew about it.
- BetaCygni 8y ago
  I trust the file signatures, but if you need to write a full article arguing something is secure then it can be made more secure by making the system simpler and more standard.
  - pritambaral 8y ago
    The apt system is simpler. HTTPS is merely more popular, and breaks existing apt use-cases.
  - widforss 8y ago
    You are going to become very upset when you discover the simplicity of TLS.
xorcist 8y ago
> It would not be able to do so if APT was using HTTPS. Oh, you are in for a surprise when you find out what middleboxes really do these days.

lucideer 8y ago

TL;DR > providing a huge worldwide mirror network available over SSL is [...] a complicated engineering task > A switch to HTTPS would also mean you could not take advantage of local proxy servers

kiwijamo 8y ago
My local Debian mirrors support HTTPS, and I assume other mirror sites worth their salt do too. Easy enough for Debian to redirect to your local mirror.
- pritambaral 8y ago
  The local apt-cacher-ng instance I run in my office network cannot be redirected to by Debian, because cannot be aware of it. The apt client will need to build support for local proxies. As it stands right now, apt-cacher-ng cannot work with https sources.
  - snuxoll 8y ago
    Fedora handles this use case beautifully with MirrorManager, which includes the EPEL repos as well. All of the logic is server side, when a yum/dnf client connects to the Metalink server to fetch a mirror list from our IP block it gets sent our internal mirror - I wish more distros had similar setups.
    - pritambaral 8y ago
      So, the public metalink server is aware of your internal mirror?
      - snuxoll 8y ago
        Yes, the mirror is configured as private and is only served to machines in my IP range - since it’s on the internal network it does nobody else good to have access.

LeonidasXIV 8y ago

Yes, I just love Debian not being able to update libsexy2 because some stupid filtering box blocks "sex" in URLs.

Dormeno 8y ago

One important factor this article left out is upgrades. If the given HTTPS implementation is broken because of what is now insecure protocols, insecure ciphers etc. Older systems can't update from the mirror if it's updated to use a 'secure' HTTPS configuration while it only supports the 'vulnerable' solution. If HTTPS is left insecure, then it is not much different from using HTTP. APT's methodology avoids this and as the current signing and protection mechanisms are file based, the worst case scenario is introducing a new file with a new cryptographic signature along side the old schema, to support still updating a system running old security mechanism. In comparison, trying to run multiple HTTPS servers with different configurations for specific versions of the system being updated would be a significant engineering effort, especially for mirrors.

da_chicken 8y ago
Huh? All you would do is configure the web server running your apt mirror site to serve the same content on both HTTP and HTTPS ports. If the client want to use TLS, they connect to HTTPS. If they want to use plain HTTP, they connect to HTTP. Both sites serve the same content, which is just a series of flat files. AFAIK, the client is responsible for determining the correct versions for the installed distro based on the indices. This is what many mirrors already do: http://mirrors.lug.mtu.edu/debian/ http://mirrors.lug.mtu.edu/debian/ https://mirrors.lug.mtu.edu/debian/ https://mirrors.lug.mtu.edu/debian/
- toast0 8y ago
  If your installed version is configured for https, but is incapable of using TLS 1.2, because it's rather old, at some point soon, a modern mirror would no longer allow it to connect as 2019 (or maybe 2020) seems to be shaping up as the year to kill support for TLS 1.0 and 1.1. Meanwhile, an http config would continue to work.

aboutruby 8y ago

Should be HTTPS by default just for the privacy of downloading packages without any intermediaries knowing the package names. It could easily be collected and used in attacks against users of vulnerable versions.

gnulinux 8y ago
Did you even read the article? This is explained at length. Https doesn't give you that benefit since attacker can still single out package based on length and in https address is in plaintext.

debiandev 8y ago

HTTPS adds very little privacy in this context. The mirror IP address is in cleartext. Also, a smart observer might be able to detect APT traffic by analyzing the timing. If you want privacy, APT supports Tor and there are mirrors providing onion services: https://blog.torproject.org/debian-and-tor-services-available-onion-services https://blog.torproject.org/debian-and-tor-services-availabl...

iheartpotatoes 8y ago
I had no idea APT supports Tor, very cool! I don't think the OP knows that either.
- gnulinux 8y ago
  Apt has supported HTTPS and tor since forever. Aws offers https mirror. OP is about defaults. If you want you can switch to https or tor or http.

alsadi 8y ago

Those arguments are invalid. Because debian/ubuntu fail to use https regimes like egypt/syria can track people who try install tor and they can cherry-pick block repos based on package name. I'm sorry for not liking your favorite color and distro. Please deal with it. And btw they don't digitally sign their package too (they sign separated meta data file having checksum which is not equivalent of embeding signature inside the package and validate it). Compare that to yum/rpm which use secure https and signed rpm and signed metadata (both the medium and the payload are secured)

bnegreve 8y ago
> Regimes like egypt/syria can track people who try install tor and they can cherry-pick block repos based on package name. They say https would not add privacy in this context because the package size (almost) uniquely determine the package name. Why is this invalid?
- onion-soup 8y ago
  "Why do you need a speedometer when you can just calculate your current speed using tachometer, odometer and time, it's real simple man"
  - AstralStorm 8y ago
    It is. You want to download Tor in some hard to track way, you probably shouldn't use an easily trackable source. There are better options including getting sent an email and torrents. And given the scope of the attacker, fingerprinting by size and server is trivial so easily https adds nothing related to anonymity nor security.
  - bnegreve 8y ago
    Ok, fair enough.
- rocqua 8y ago
  You can block based on a name because you see the name before the package is sent. You can't block based on package length, because you need to let the entire update through before you know the length. At that point, it's too late to block. Buffering the entire message doesn't work because TCP expects ACKs.

izzytcp 8y ago

GPG = Integrity/Safety | HTTPS = Confidentiality I want both, ppl who only want the first one are stupid. Those who don't do HTTPS are lazy and reckless, it's free & easy.

ctz 8y ago

The claims on this site are easily falsifiable by past bugs on debian's own bug tracker: eg https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710229 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710229 I've personally experienced this too: using apt in the presence of a captive portal replaces random bits of `/var/cache/apt` with HTML pages, breaking future updates until you manually find and fix the problem yourself.

pascal_cuoq 8y ago
The reverse argument also works: using HTTPS may lead you to link and expose, say, OpenSSL where you otherwise would not have needed to. OpenSSL has had dozens of vulnerabilities in the past: https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/news/vulnerabilities.html Some of these vulnerabilities have the potential for arbitrary code execution, leaving you worse off than the simpler solution based on the verification of cryptographic signatures that has fewer vulnerabilities by virtue of doing less. The discussion at https://whydoesaptnotusehttps.com https://whydoesaptnotusehttps.com is about the protocol. You can add implementation bug risks to the discussion if you want, but then include the risks from both the approaches being discussed.
- zamadatix 8y ago
  You've proposed a reverse argument to an argument that was never made. ctz never said anything about vulnerabilities or implementation issues, they said a captive portal is a problem for apt over HTTP but not HTTPS. This is also true of ISPs that like to insert things into HTTP sessions.
  - pascal_cuoq 8y ago
    “bugs”

scoot_718 8y ago

Finding out the packages based on file sizes? Nope - https would hide the sizes of individual files within the entire session.

rocqua 8y ago
Timing alone would go a long way.
gnulinux 8y ago
Attacker can simply count the bytes. They can buffer one packet, send ack, and reject it based on bytes transferred. Also it's trivial know when next package starts. Apt doesn't steam all packages at once, it first send first package with http keep alive then waits until client orders the second package.

flyGuyOnTheSly 8y 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[2]. HTTPS would therefore only be useful for downloading from a server that also offers other packages of similar or identical size. That seems like a false dilemma imho. What's preventing APT from splitting up downloads into identically sized chunks of say 4kb?

deleted 8y ago

[deleted]

dpcx 8y ago

I think https by default would be a wonderful addition. I understand the complexities from the project's perspective. I understand the users wants for privacy. If the project not defaulting to https is that much of a privacy issue for you, set up a local mirror then point your boxes to that. Yes, someone could potentially still snoop your local network. But if they can do that, you've got bigger issues to worry about than the fact that they can see what packages you're installing. https://www.debian.org/mirror/ftpmirror https://www.debian.org/mirror/ftpmirror

lorenzhs 8y ago

Apparently Windows Update uses TLS without encryption (null cipher) which still provides integrity and authentication: https://twitter.com/swiftonsecurity/status/745333018697469953 https://twitter.com/swiftonsecurity/status/74533301869746995.... Debian's signing achieves the same result by signing the package list containing the packages' hashes with a known key.

da_chicken 8y ago
As far as I'm aware, all Windows Update packages are also digitally signed.

rocqua 8y ago

Besides the privacy issue of sending package names clear-text, there is a second non-mitigated issue: Censorship. An MitM could selectively block certain package being installed / update. Imagine using this to prevent: Bitcoin being installed / enforce a ban on crypto without backdoors / block torrent installations. This doesn't work as well with the 'recognize package size' method because you need to download the entire package before you know the size. Given the need for Ack in TCP, an MitM can't just buffer data until they have the entire package size.

loeg 8y ago
> This doesn't work as well with the 'recognize package size' method because you need to download the entire package before you know the size. Given the need for Ack in TCP, an MitM can't just buffer data until they have the entire package size. All they have to do is corrupt the final packet and the package checksum fails. An attacker only needs to buffer a single packet worth of data.

hyperpape 8y ago

One reason to prefer HTTPS is that in the event of a vulnerability in the client code, an attacker cannot trigger that vulnerability using a MITM attack if HTTPS is in use. One such vulnerability was recently found in apk-tools: https://nvd.nist.gov/vuln/detail/CVE-2018-1000849 https://nvd.nist.gov/vuln/detail/CVE-2018-1000849

Klathmon 8y ago
While I agree with your point, a counterpoint is that vulnerabilities in the HTTPS implementation are also possible, and by introducing HTTPS code you are increasing the surface area of possible vulnerabilities.
- andy_ppp 8y ago
  How is this making you more vulnerable that not having it? It’s like saying don’t bother having locks on your doors because they are subject to picking... not a great argument.
  - hyperpape 8y ago
    This isn't accurate. If the SSL code incorrectly trusts the wrong server, then you're no better off but also no worse off. If the code has a RCE vulnerability caused by bad parsing logic, then you're worse off than you would be without it. My counter-counterpoint is that while OpenSSL had (has?) horrible security issues, it's still worth using HTTPS in principle, because a modern internet connected system that has no trustworthy SSL library is going never not going to have security problems. Whether it's hardening OpenSSL, shipping BoringSSL, or anything else, systems just have to get this right, and once they do, applications like apt can take advantage of it.
    - AstralStorm 8y ago
      Problem being that such broken system might especially want to peruse package updates...
  - 8y ago

dooglius 8y ago

>To mitigate this problem, APT archives includes a timestamp after which all the files are considered stale How often is this, practically? If I'm understanding this right, each new timestamp would come only with a package upgrade, meaning the time period is quite a long time indeed, long enough for a replay attack to work. I would argue that there should be a mechanism requiring a signed the-latest-package-is-X message updated at least every day or so. Edit: it looks like this is actually what's going on. The page wasn't clear, but it is a metadata "Releases" file that is timestamped, not the packages themselves.

jkaplowitz 8y ago
The security repository generally serves up a field in its metadata saying that the data shouldn't be trusted for more than 7 days, if it hasn't changed since 2014 when I encountered this duration as part of my day-job work. It's safe to assume the trusted duration hasn't increased, at least.
- dooglius 8y ago
  http://security-cdn.debian.org/dists/stable/updates/Release http://security-cdn.debian.org/dists/stable/updates/Release is 10 days in the future. I still think it should be shorter, as it's pretty conceivable to exploit a 1-day vulnerability in that timeframe, but it's not that bad.

3pt14159 8y ago

This argument boils down to two things: One side: We want performance / caching! Other side: We want security! Both sides sometimes argue disingenuously. It's true that caching is harder with layered HTTPS and that performance is worse. It's also true that layering encryption is more secure. (It's what the NSA and CIA do. You smarter than them?) Personally, I'd default to security because I'm a software dev. If I were a little kid on a shoddy, expensive third world internet connection I'd probably prefer the opposite. I just wish it were up to me.

eloisant 8y ago
Not in this case, just read the tl;dr in the article (you don't even need to read the whole article).
buster 8y ago
Except that this page argues, that you are not increasing security in this case.
- zeroimpl 8y ago
  But it does, because HTTPS can ensure you always get up to date data. They have a solution involving timestamps for HTTP, but that is still clearly less secure than the guarantee from HTTPS.
- shittyadmin 8y ago
  This page is wrong, for example they claim there's no privacy increase here but quite clearly there's a huge difference between an attacker being able to tell "you're downloading updates" and an attacker being able to tell "you're downloading version X.Y of Z package" - worse, that information could actually later be used to attack you based on the fact that the attacker now knows what version to find vulnerabilities in, including non-exposed client software for email, documents, browsers, etc. It's a relatively insignificant security benefit for most, but could prove an important one for those who targeted attacks are used against.
  - 8y ago

lifthrasiir 8y ago

We like to talk about, say, the compromise of integrity and/or authenticity, information leak and so on, but they are not only things TLS/HTTPS was prepared for. Indeed, it is often overlooked that we have two kinds of exploitations in this space. I tend to label them as "active" and "passive". One of the best known passive exploitations is a JavaScript injection from ISP---Comcast did it in 2017 [1] for example. They alone are typically harmless or annoying at best, but they are indicative of the real security problem lurking around, and often can evolve into active exploitations. It might be probably true that APT is a simple service that does not require the full TLS capability. But APT is only prepared for active exploitations. Passive exploitations will effectively compromise the availability, by compromising the integrity in the relatively predictable way. I don't think APT is also prepared for passive exploitations---casual users will be much more prone to them. [1] https://forums.xfinity.com/t5/Customer-Service/Are-you-aware/td-p/3009551 https://forums.xfinity.com/t5/Customer-Service/Are-you-aware...

jdfellow 8y ago

My corporate network used a transparent https man-in-the-middle proxy. That is, transparent as long as you're using a Windows machine that has been configured by the help desk and using applications that utilize the Windows certificate store, which doesn't include git, pip, or npm. If pip or npm used gpg signing of packages rather than https, this wouldn't be a big deal. But as it stands, it's a nightmare on various Windows systems, Linux boxen, and Docker images to get the code you need.

crankylinuxuser 8y ago

There's also a current and ongoing "discussion" (I say pejoratively) regarding the same issue with VideoLAN. They can't (easily) use HTTPS because they don't control the mirrors. However the package download/update itself is also signed with GPG, thus guaranteeing tamper resistance. https://twitter.com/videolan/status/1086672630994927616 https://twitter.com/videolan/status/1086672630994927616

allan_ 8y ago

nothing justifies debian making you `apt-get install apt-transport-https` over `http` before you can add your own repos which are https only of course. but hey, it's debian.

adenner 8y ago

another option for a "secure" connection is to use the apt onion services from tor https://blog.torproject.org/tor-heart-apt-transport-tor-and-debian-onions https://blog.torproject.org/tor-heart-apt-transport-tor-and-...

sgjohnson 8y ago

There are benefits in switching to HTTPS even if it's not done for security reasons. Namely, HTTP/2. However, I'm not sure if the benefit in speed would be measurable for apt.

toast0 8y ago
HTTP/2 is more likely to be a downside than an upside for apt. You would have additional framing overhead, and I can't see a benefit over pipelined http/1.1 be (which is definitely doable because all the requests are get for static files). Maybe header compression of the small headers could be a very minor win. Multiplexing within a tcp stream is at best neutral for this case, but probably negative: on the client side, it means the possibility of multiple partial files instead of one; on the server, it means more parallel demand on the file system.
anfilt 8y ago
How is HTTP/2 a benefit for a file store? The design of HTTP/2 helps websites more. It supports push since webpages include resources that a server knows a client is going to need anyways. This avoids request latency for websites. It also allows connection reuse (via multiplexing. However, again this is mostly helpful for websites. Decrease latency by avoiding tcp hand shake. It allows for slightly smaller headers since it's a binary protocol. However, pretty much none these really help with large file downloads, and other use cases like APT. Even the headers will be dwarfed by the files themselves, and the header information is probably already pretty minimal. Also HTTP/2 does not require TLS it's just pretty much all the browsers ignore that the standard does not require TLS. However, they are trying to push for more encrypted traffic. A decision I don't really think browsers should be making.

hannob 8y ago

I guess I can copy over a comment I made when this previously made rounds: I have a few problems with this. The short summary of these claims is “APT checks signatures, therefore downloads for APT don’t need to be HTTPS”. The whole argument relies on the idea that APT is the only client that will ever download content from these hosts. This is however not true. Packages can be manually downloaded from packages.debian.org and they reference the same insecure mirrors. At the very least Debian should make sure that there are a few HTTPS mirrors that they use for the direct download links. Furthermore Debian also provides ISO downloads over the same HTTP mirrors, which are also not automatically checked. While they can theoretically be checked with PGP signatures it is wishful thinking to assume everyone will do that. Finally the chapter about CAs and TLS is - sorry - baseless fearmongering. Yeah, there are problems with CAs, but deducing from that that “HTTPS provides little-to-no protection against a targeted attack on your distribution’s mirror network” is, to put it mildly, nonsense. Compromising a CA is not trivial and due to CT it’s almost certain that such an attempt will be uncovered later. The CA ecosystem has improved a lot in recent years, please update your views accordingly.

xcaaa 8y ago
How is it not trivial if rogue organizations like "Staat der Nederlanden" have default certificates in the browser? Hint: The Netherlands is world leader in surveillance of its own citizens and inhabitants.
- vegardx 8y ago
  Because they would be caught doing it very quickly. There are so many ways to detect this.
  - shittyadmin 8y ago
    And ultimately none of those ways to detect this aren't useful against a sufficiently targeted attack with direct access to the signing key. It's one thing if you sign a bad key for Google.com, publish it in CT logs and then put it up on the public internet - it's quite another if you sign a bad key for midsizecompany.com, keep it out of the CT system and use it only in a targeted attack against non-technical individuals who are unlikely to examine a certificate or use things like Certificate Watch. With that said, I still believe serving it over HTTPS would be a substantial improvement. Perhaps pin the cert or at least the CA out of the box to prevent such attacks.

lreeves 8y ago

Yeesh, as someone who has had to troubleshoot more than a few times HTTP payloads that were mangled by shitty ISP software to inject ads or notifications I would love HTTPS as a default to prevent tampering. I get the arguments against it, but I have 100% seen Rogers in Canada fuck up HTTP payloads regardless of MIME types while rolling out "helpful" bandwidth notifications. Signatures will tell you yes this is corrupt but end-to-end encryption means that the person in the middle can't even try.

fyjvd90 8y ago
Likewise, integrity of the download is the primary reason I’ve switched downloads to HTTPS too. The argument that singed downloads is enough fails to address what the user is supposed to do after the integrity has failed? A redownload can result in the same tampered with file. This isn’t hypothetical btw, it happens in the real world, I’ve had ISPs in Ireland and South Africa damage downloads due to their injections and users don’t care if it’s their ISP, they get pissed off at you unfortunately.

TedLePoireau 8y ago

The "Date, Valid-Until" timestamp mitigates replay-attack, cool. But what if a vulnerability is discovered in a package and an MITM attack prevent you from downloading the new patched version, making you believe your system is up to date although it's not ?

AstralStorm 8y ago
No, apt then shows a message about failing to download fresh update lists. For security repo, the period it's 10 days.

jopsen 8y ago

Lots of reasons to use HTTPS most notable is defense-in-depth. A good design always aims to have multiple othorgonal security mechanisms in place.

jen20 8y ago

I'm somewhat surprised that no-one has (yet) linked to this post [1] by Joe Damato of Packagecloud, which digs into attacks against GPG signed APT repos, or the paper which initially published them [2]. The post makes clear in the third paragraph: "The easiest way to prevent the attacks covered below is to always serve your APT repository over TLS; no exceptions." [1]: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/ https://blog.packagecloud.io/eng/2018/02/21/attacks-against-... [2]: https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.p...

fucking_tragedy 8y ago
Thanks for posting these, I was unaware that they even existed.

ktrask 8y ago

At a research institute I worked for, we had a proxy server that intercepted http. The antivirus software on the proxy made it impossible to download some security updates once in a while. Fortunately it was possible to change the ubuntu URIs to https:// https:// to use HTTPS and the broken antivirus sofwate did not intervene anymore.

boxingdog 8y ago

well, this is like saying your car does not need airbags because it already has brakes and your gonna die anyway

jancsika 8y ago

I bet there are many FLOSS advocates who don't read that page as being the result of a cost-benefit analysis. They read it as an inspiring story of the rebels winning one against the https Empire. Because I never see the caveat wrt apt that, "of course, we are a super edgy edge-case that should not be used as a model to rationalize a knee-jerk refusal to use SSL for common cases." I say this because I've corresponded with such advocates about a completely common case for SSL-- setting up a LetsEncrypt certicate, say. The response I often get doesn't make any sense unless I assume they read a page like this and remembered the feels while forgetting all the relevant details that separate apt from their common case.

kerng 8y ago

Using https is a basic security principle - not using it means you are doing security wrong and someone will be bitten by it. They can argue and justify why they do it as much as they want, that actually shows a bit of security immaturity on their side.

gnode 8y ago

Layering HTTPS on top of the existing authentication system adds the obvious benefit of confidential communication, such that an eavesdropper can't see what packages you're downloading. There's an argument that you can infer the package from the size of download, but this is defeated by downloading partial regular sized chunks of the file with some overlap to mask the actual size. The only sensible argument against HTTPS seems to be infrastructure cost. This made more sense in the past, but nowadays hardware crypto acceleration (e.g. AES-NI) is commonplace, and certificates can be obtained for free. Ultimately it's up to mirrors to decide if they're willing to provide HTTPS.

alexnewman 8y ago

Every other vendor, uses https and also signs packages. Clearly they are all wrong and apt is the only correct one.

deleted 8y ago

[deleted]

throw2016 8y ago

Beware of strangers bearing gifts. There is a lot of https scaremongering from a certain subset of people with objectives one finds difficult to understand. If they were genuinely concerned about privacy, security and surveillance they would have a lot to say about the out of control surveillance economy and its participants including their employers, the security model of browsers, mobile operations systems, javascript, systemic user stalking and hoovering up data. Yet those stories are mainly driven by people outside the tech ecosystem and within there is mostly silence interspersed with vague economic justifications so there is something truly bizarre about https extremism on the grounds of privacy. If your packages are already signed why do you need a middleman? That is a better trust model for a distributed Internet than a centralized CA that is not accountable to individuals and can be compromised by power. Here people are neck deep in business models stalking people online 24/7 and tracking their location and some are 'concerned' about protecting the list of packages you download?

0xdeadbeefbabe 8y ago
> Here people are neck deep in business models stalking people online 24/7 and tracking their location and some are 'concerned' about protecting the list of packages you download? That's believable. "There are a thousand hacking at the branches of evil to one who is striking at the root." - Henry David Thoreau. Nice word "hacking". Edit: Uh oh maybe Thoreau was pro CA.

l0b0 8y ago

So they don't consider privacy beyond which host I contact, which is weird, because I'm pretty sure which version of packages I have is relevant to an attacker. And in case of a zero-day exploit it would be really handy not having to wait for some global timeout during which I won't see any updates.

amelius 8y ago

Question: does APT work with HTTP proxies, which e.g. some company networks impose as the only means of internet connectivity?

guardiangod 8y ago

As an exploit analyst currently focusing on network traffic, can we stop all this fascination with SSL/TLS? TLS is incredible, but let's use the right tool for the job. Contrary to Let's Encrypt motto, applying TLS to _everything_ can be bad for security. Let's Encrypt, when are you going to revoke placeimg.com's certificate? The site has been pushing Exploit Kit's malicious payloads since Jan 18 2019 via SSL. Many Flash/IE users are getting infected because most firewalls are unable to peer into SSL tunnels signed by you. (To be fair, Let's Encrypt is not the only cert authority getting abused (Comodo, yes you))

josteink 8y ago

With HTTPS, I need to trust every government in the world to not interfere with CAs. With GPG, I only need to trust Debian to give me Debian. Is there really a question about security here?

forty 8y ago

I wish APT used HTTPS if only to be able to tell my proxy "only allow HTTPS" and never have to worry about unencrypted traffic ever. Currently it's the only HTTP trafic my server are generating. Plus it's polluting my proxy logs as instead of having only the domain as it's the case for all the other log, I have the full URLs :)

jopsen 8y ago

> providing a huge worldwide mirror network available over SSL is not only a complicated engineering task Nobody said each mirror couldn't have its own certificate and its own domain. The host names of these mirrors are usually obtained from a trusted source. HTTPS in addition to GPG signatures does no harm. It also means that one would have to compromise two entities, my distro's GPG key and my mirror's certificate.

Rapzid 8y ago

> HTTPS does not provide meaningful privacy for obtaining packages. That's a very subjective and circumstantial statement being passed off as fact. Just because one can list a few scenarios where HTTPS wouldn't prevent a malicious actor from achieving their goals, doesn't mean HTTPS does not increase security/privacy for apt in other situations. Further, in certain contexts, guessing and proving are not fungible.

alexnewman 8y ago

I guess that explains why I have install ca-certificates, and ubuntu doesn't ship with them.

furiousindexer 8y ago

I am seeing quite a bit of misinformation about how package managers work so I'd love to share what I have learned. I work with index files on a daily basis, and we might possibly generate more index files than any other organization on the planet. Here is my chance to share some of this knowledge! TLDR/Summary We can trust the Release file because it was signed by Ubuntu. We can trust the Packages file because it has the correct size and checksum found in the Release file. We can trust the package we just downloaded because it is referenced in the Packages file, which is referenced in the Release file, which is signed by Ubuntu. Some basic package manager principles I work with APK, DEB, and RPM based package managers and each of them behave very similar. Each repository has a top level file, signed by the repository's maintainer, that includes a list of files found in the repository and their checksums. When your package manager does an update, it looks for this top level file. For DEB based systems, this is the Release file For APK based systems, this is the APKINDEX.tar.gz file For RPM based systems, this is the repodata.xml file These files are all signed by the repository's gpg key. So the Release file found athttp://us.archive.ubuntu.com/ubuntu/dists/bionic/Release http://us.archive.ubuntu.com/ubuntu/dists/bionic/Release and is signed by Ubuntu and the gpg key is included in your distribution. Let's hope Ubuntu doesn't let their gpg key into the wild. Assuming that Ubuntu's gpg key is safe, this means that the system can verify that the Release file did in fact come from Ubuntu. If you are interested, you can click on the previous link, or navigate to Ubuntu's repository and open up one of their Release files. Release file In the Release file you'll see a list of files and their checksum. Example:55f3fa01bf4513da9f810307b51d612a 6214952 main/binary-amd64/Packages 9f666ceefac581815e5f3add8b30d3b9 1343916 main/binary-amd64/Packages.gz 706fccb10e613153dc61a1b997685afc 96 main/binary-amd64/Release 9eae32e7c5450794889f9c3272587f5e 1019132 main/binary-amd64/Packages.xz 5dd0ca3d1cbce6d2a74fcc3e1634ac12 96 main/binary-arm64/Release The left column is the checksum, then the size of the file, and lastly the location of the file. So we can download the files referenced in the Release file and check them for the correct size and checksum. The Packages or Packages.gz file is the one we care about in this example. It contains information about the packages available to the package manager (apt in this case but again, almost all of the package managers behave very similar). Packages file Since we know that we can trust the Release file (because we have proven it was signed by Ubuntu's gpg key), we can then proceed to download the contents of the Release file. Let's look at the Packages file specifically as it contains a list of packages, their size, and checksum. Filename: pool/main/a/accountsservice/accountsservice_0.6.45-1ubuntu1_amd64.deb Size: 62000 MD5sum: c2cffd1eb66b6392f350b474e583adba SHA1: 71d89bd380a465397b42ea3031afa53eaf91661a SHA256: d0b11d1d27fe425bc91ea51fab74ad45e428753796f0392e446e8b2450293255 The Packages file includes a list of packages with information about where the file can be found, the size of the file, and various checksums of the file. If you download a file through commands like apt install and any of these fields are incorrect, apt will throw an error and not add it to the apt database. It's time to debunk some myths! Can an attacker send me a fake Release file? Sure, but apt will throw it out because it's not signed by Ubuntu (or whoever your repository maintainer is like centos, rhel, alpine, etc) Can an attacker send me an old index from an earlier date that was signed by Ubuntu that has old packages in it with known exploits? Sure, but apt will throw it out because it will have a date (in the Release file) that is older than what is stored in the apt database. For example, the current bionic main Release file has this date in it: Date: Thu, 26 Apr 2018 23:37:48 UTC So if you supply it with a Release file older than that timestamp, it will throw it out because it is older than what it currently knows about. I hope this helps clear the air! Shameless plug. If you are serious about security and not just compliance, check out our Polymorphic Linux repositories. https://polyverse.io/ https://polyverse.io/ We provide "scrambled" or "polymorphic" repositories for Alpine, Centos, Fedora, RHEL, and Ubuntu. We use the original source packages provided in the official repositories and build the packages but with memory locations in different places and ROP chains broken. Installation Installation is a one line command that installs our repository in your sources.list or repo file. There is no agent or running process installed. It is literally just adding our repository to your installation. The next time you do an `apt install httpd` or `yum install docker` you'll get a polymorphic version of the package from our repository. You can see it in action in your browser with our demo: https://polyverse.io/learn/ https://polyverse.io/learn/ What does it do? Many of the replies in this post referenced an attacker tricking a server into an older version of a package that has a known exploit. We stop this. Even if you are running an old version of a package, with a known exploit, memory based attacks will not work on the scrambled package because the ROP chain has been broken or as we call it "scrambled". So with our packages, you can run older versions of a package and not be effected by the known exploits. This also means that you are protected from zero day attacks just by having our version of the package. FREE! For individuals and open source organizations you can use our repositories for free. I hope you try it out!

sepent 8y ago

"HTTPS does not provide meaningful privacy for obtaining packages. As an eavesdropper can usually see which hosts you are contacting, if you connect to your distribution's mirror network it would be fairly obvious that you are downloading updates." It is a dangerous mistake to decide what kind of privacy people need. Privacy should be absolute and without conditions. What if you live in Iran? Some Ubuntu packages are already inaccessible due to government's pornography keywords censorship. E.g. I can't download "libjs-hooker" from this http link http://archive.ubuntu.com/ubuntu/pool/universe/n/node-hooker/libjs-hooker_0.2.3-1_all.deb http://archive.ubuntu.com/ubuntu/pool/universe/n/node-hooker... from Iran. What if the government decides to censor the "tor" package?

isostatic 8y ago

https://usn.ubuntu.com/3863-1/ https://usn.ubuntu.com/3863-1/ "Max Justicz discovered that APT incorrectly handled certain parameters during redirects. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could potentially be used to install altered packages." Far easier to do a MITM attack when apt isn't using https by default Security is best in layers

jwilk 8y ago

Previous discussion: https://news.ycombinator.com/item?id=16221563 https://news.ycombinator.com/item?id=16221563