Why is there no https transport for debian apt tool?

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.


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.


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.