With all the paranoia that came with NSA revelations, I'm wondering why the Debian package installation mechanism does not support HTTPS for its transport, let alone use one by default.

I know Debian packages have some sort of signature validation using GPG, but still, I don't think using HTTPS transport instead of HTTP would be too hard, considering how crucial this is security-wise.

Edit: I mostly want to protect myself from MitM attacks (including just traffic sniffing), not Debian mirror administrators. HTTP repositories put the whole system set up on the table for anyone snooping traffic to Debian mirrors.


There is. You need to install the package apt-transport-https. Then you can use lines like

 deb https://some.server.com/debian stable main

in your sources.list file. But usually that's not necessary, since the entire content is public anyway and it adds encryption overhead and latency. Since you don't trust an attackers public key, even http traffic is safe from MitM attacks. apt will warn you and fail to install the packages when an attacker injects manipulated packages.

EDIT: As mentioned in the comments it is indeed more secure to use the TLS repository. Research shows that using apt on unencrypted repositories can indeed pose a security risk as the HTTP transport is vulnerable to replay attacks.

  • 7
    No, most mirrors do not support https. Simply because it doesn't make much sense to encrypt this kind of traffic. Packages are being verified anyway and the information is public. – Marco Sep 11 '13 at 12:33
  • 6
    I can think of a couple reasons I might still prefer to download over TLS: 1) I might care about my privacy when installing packages, and 2) there might be bugs in the package signature checking code, which an MITM could exploit. – Jack O'Connor Mar 24 '16 at 19:46
  • 2
    @JackO'Connor, while the first objection about privacy is understandable, the second is like saying I like websites to sign their contents with PGP keys because there might be bugs in TLS code. Both PGP and TLS establish trust; you don't need both for that. – Paul Draper Apr 25 '16 at 5:37
  • 9
    @Marco your answer is incorrect; numerous research papers have shown both APT and YUM repositories to be vulnerable to replay attacks when the repository is accessed via HTTP, even with GPG signatures. Repositories should only be accessed via TLS, 100% of the time. – Joe Damato Oct 21 '16 at 10:00
  • 8
    Here is the paper @Joe Damato refers to - also see his answer here – SauceCode Oct 22 '16 at 2:44

Your assumption is wrong: you can use HTTPS downloads. You just have to find a mirror that supports it, and put its URL in your list of sources. You'll need to install the apt-transport-https package.

Debian doesn't make HTTPS downloads easy because there is very little benefit. Debian package distribution already includes a mechanism to verify packages: all packages are signed with Gpg. If an active man-in-the-middle redirects your traffic to a server with corrupted packages, the corruption will be detected because the GPG signatures won't be valid. Using GPG rather than HTTPS has the advantage that it protects against more threats: not just against active man-in-the-middle on the end-user connection, but also against a rogue or infected mirror or other problems anywhere in the package distribution chain.

HTTPS does provide a slight privacy advantage in that it obscures the packages that you download. However a passive observer can still detect traffic between your computer and a package server, so they would know that you're downloading Debian packages. They could also get a good idea of which packages you're downloading from the file sizes.

The one place where HTTPS would help is for bootstrapping trust, to get a known-valid installation image. Debian doesn't seem to provide that: there are checksums of installation media, but only over HTTP.

  • There is HTTPS version of installation media : cdimage.debian.org/debian-cd – Fedir RYKHTIK Jun 23 '17 at 8:41
  • 2
    Very little benefit? What about justi.cz/security/2019/01/22/apt-rce.html? – Aaron Franke Jan 23 '19 at 2:18
  • @AaronFranke One specific bug which is easier to exploit with HTTP than with HTTPS counts a very little benefit, yes. It's not as if HTTP had a larger attack surface than HTTPS: in fact HTTPS itself has a larger attack surface since it involves more code. So it isn't even a net benefit at all: it's a trade-off between two marginal risks. – Gilles 'SO- stop being evil' Jan 23 '19 at 9:10

Just recently I came over the issue with my Company's apt repository. The problem was that if we use standard http transport anybody else can get package easily. As Company is packaging its own proprietary software and does not want to share it with everybody, http transport becomes a problem. Not a tragedy but a problem. There is couple of ways how to limit access to package - firewalling, restricting access on web-server level, using ssh as a transport. Quite easy to consume reading on this topic could be found here: Restrict Access To Your Private Debian Repository

In our case, we decided to use https transport + client certificate authentication. Briefly, all it takes is:

  1. Prepare self-signed certificates, client and server (using easy-rsa);
  2. Configure webserver which fronts repository to accept only https; In case of nginx it might look like:

    server {
      listen 443;
      root /path/to/public;
      server_name secure_repo;
      ssl on;
      ssl_certificate /etc/nginx/ssl/server.crt;
      ssl_certificate_key /etc/nginx/ssl/server.key;
      ssl_session_timeout 5m;
      ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
      ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:;
      ssl_prefer_server_ciphers on;
      ssl_client_certificate /etc/nginx/ssl/ca.crt;
      ssl_verify_client on;
      location / {
         autoindex on;
  3. Put client certificate,client key and ca certificate to /etc/apt/ssl and, in case with Ubuntu, add 00https file to /etc/apt/apt.conf.d:

    Debug::Acquire::https "true"; Acquire::https::example.com { Verify-Peer "true"; Verify-Host "false"; CaInfo "/etc/apt/ssl/ca.crt"; SslCert "/etc/apt/ssl/client.crt"; SslKey "/etc/apt/ssl/client.key"; };

Keep in mind, that if you are using self-signed certificate it is important to switch off host verification: Verify-Host "false"; If you don't do this, you'll catch an error: SSL: certificate subject name (blah-blah-blah) does not match target host name 'example.com'

And here we go, there is no more unauthorized access to repository. So this is quite useful and powerful thing.

  • 3
    Thanks for the great answer. But I think the main issue is still there. HTTPS should really become the default protocol for transfers over the web and debian packages in particular. The argument should not be why HTTPS, it should be why not? – zaadeh Mar 7 '15 at 14:07
  • 1
    @aalizadeh, I agree with you, there is overhead when using https, but there is no massive overhead. I think, the main reason why https is not a default transport is that some organizations explicitly prohibit any encrypted traffic (as they want to be able to stick their noses in what the employees are doing over Internet), which means that repositories have to support both http and https transports. May be there are other considerations – at0S Mar 9 '15 at 2:50
  • 1
    Using »Verify-Host "false";« is wrong, even with self-signed certificates. You need to make your clients aware of the (correct) server certificate instead. – Axel Beckert Dec 16 '16 at 23:22
  • 1
    Indeed, but here my clients were only internal systems. So instead of creating all proper pki infrastructure I cut the corner. And yes, later on pki was settled properly and Verify-Host false; was remove. And yes, the point is valid. – at0S Sep 18 '17 at 23:30
  • 1
    with ubuntu xenial the apt packages are fetched as unprivileged user _apt, can you please update this thread with details on how you managed or resolved the file permission issues. – David Jan 3 '18 at 22:49

Note that because of vulnerabilities like


... which circumvents InRelease signing, it's probably a good idea to configure HTTPS anyway.

And this isn't a single example - many other update systems that default to HTTP have also had a history of signature verification failures.

Security-critical update mechanisms should use both HTTPS and signature verification to be robust. Each mitigates a failure of the other.

  • 1
    And now this one as well: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. InRelease signing is not sufficient. "But moving all mirrors to HTTPS will take time and coordination!". Yes. Start now. This will not be the last InRelease failure. – Royce Williams Aug 21 '18 at 15:14
  • 1
    Here's another example, from a different ecosystem - Alpine. Its package management system doesn't use HTTPS by default, and relies solely on signing to verify package integrity ... and that verification had a remotely exploitable bug in September 2018: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine should start moving now to using HTTPS by default. – Royce Williams Sep 13 '18 at 20:36
  • (Full disclosure: my own gist, but it's the only reference I know of), here is a list of all failures of client-side signing verification failures that I'm aware of. The list is non-trivial in size, and grows regularly. Adds welcome. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004 – Royce Williams Apr 11 '20 at 20:22

For the "anonymity" use-case there is also apt-transport-tor which then allows you to put URIs like tor+http:// in sources.list files. This is much better anonymity protection than simply encrypting the connection to your mirror.

For example, a local observer would still know that you're updating or installing software even with HTTPS, and can probably make some decent guesses as to which of those you're doing (and possibly even which packages, based on size).

Debian provides APT repositories via Tor "Onion services" so you can get end-to-end encryption (similar to TLS) without having to trust the domain-name system. See onion.debian.org for all Debian services available this way. The main Debian FTP repository is at vwakviie2ienjx6t.onion

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.