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.


5 Answers 5


Update 2017: Apt 1.5 supports https out the box. It is no longer necessary to install package apt-transport-https separately.

There are multiple attacks and vulnerabilities against apt with http repositories:

To use https repos in sources.list you need to install the package apt-transport-https.

 deb https://some.server.com/debian stable main
  • 8
    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, 2013 at 12:33
  • 10
    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. Mar 24, 2016 at 19:46
  • 3
    @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. Apr 25, 2016 at 5:37
  • 11
    @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, 2016 at 10:00
  • 8
    Here is the paper @Joe Damato refers to - also see his answer here
    – SauceCode
    Oct 22, 2016 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 Jun 23, 2017 at 8:41
  • 3
    Very little benefit? What about justi.cz/security/2019/01/22/apt-rce.html? Jan 23, 2019 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. Jan 23, 2019 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.

  • 4
    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, 2015 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, 2015 at 2:50
  • 2
    Using »Verify-Host "false";« is wrong, even with self-signed certificates. You need to make your clients aware of the (correct) server certificate instead. Dec 16, 2016 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, 2017 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, 2018 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. Aug 21, 2018 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. Sep 13, 2018 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 Apr 11, 2020 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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .