0

As stated in the previous question: How can i force apt-get or apt to use only https connections

deb https://deb.debian.org/debian bookworm main
deb https://security.debian.org/debian-security bookworm/updates main
deb https://deb.debian.org/debian bookworm-updates main

security.debian.org doesn't work if I use https protocol.

With ubuntu I have similar problems in updating apt-get cache with https protocol.

Now, isn't considered a major security issue using plain http in order to download updates for your operative system ?

I'm scratching my head in order to understand why in 2023 plain http is still considered to be used aside some testing environments. Can't heavy main in the middle and mangling of packets be carried in place so that crafted packets can be dispatched and be installed on user machines?

user3450548
  • 2,868
  • 1
    Because security is still provided using GPG key signing: https://unix.stackexchange.com/a/90321/70524 HTTPS can still provide some additional security, but IMO the gap between (HTTP + package indices signed using GPG) and (HTTPS + package indices signed using GPG) is far, far smaller than the gap between HTTP and HTTPS. – muru Nov 06 '23 at 09:52
  • 1
    Does this answer your question? Why is there no https transport for debian apt tool? – muru Nov 06 '23 at 09:53
  • Want to validate a download made on a system without apt-get (or just non-Debian for Debian packages)? Have a (any) Debian box of the same version and architecture run apt-get --print-uris download foo instead of apt-get download foo: it will provide the http URL to download the package foo as well as the checksum validating it (without having to deal with the PGP part already done by apt-get). – A.B Nov 06 '23 at 14:51

1 Answers1

4

Debian and its derivatives don’t rely on TLS to secure package delivery, they rely on OpenPGP key signatures, using keys already on the system (set up during installation or added by the system administrator). This covers metadata and package contents; see How is the authenticity of Debian packages guaranteed? for details.

The other commonly-requested feature provided by TLS is confidentiality, i.e. that anyone able to spy on your traffic can’t determine what you’re doing. I don’t have the links handy but it turns out that TLS isn’t sufficient to hide package download activity meaningfully — transfer sizes are sufficient to determine which packages are being downloaded in most cases.

So TLS adds integrity, which Debian already provides, and could add confidentiality, but doesn’t in practice. It also adds some overhead and makes it more complicated to cache data (which is extremely useful for distribution package repositories); so Debian doesn’t configure it by default.

There is one feature of TLS which isn’t supported in all cases in Debian repositories: resistance to replay attacks. In a man-in-the-middle scenario, without TLS, a client can be served older versions of repository metadata and associated packages, which could be used to keep a system vulnerable. Debian repositories with frequent updates (notably, the “updates” and security suites) produce metadata which is only valid for a week, preventing replays beyond that; but stable point releases are valid until their signing key expires, so a target system could be artificially kept on an older point-release. (However in its default configuration it would still see security updates in this type of scenario.)

Of course, defense in depth is better, and there have been vulnerabilities in the past which would have been mitigated by TLS; so TLS can be enabled with most repositories.

As far as best practices go:

  • for Debian (or Ubuntu) repositories, the default setup is good enough as long as you pay attention to apt errors (but don’t let me stop you enabling TLS if you want to);
  • for third-party repositories, you should use TLS if possible (this is easier as a blanket rule than checking whether each repository is configured correctly).
Stephen Kitt
  • 434,908
  • One more feature is preventing a DoS of updates - https://unix.stackexchange.com/questions/90227/why-is-there-no-https-transport-for-debian-apt-tool?noredirect=1&lq=1 and https://unix.stackexchange.com/a/317916/70524 mention replay attacks. – muru Nov 06 '23 at 10:00
  • @muru those have been addressed in apt since then. – Stephen Kitt Nov 06 '23 at 10:01
  • I suppose you're talking about the Valid-Until field you mentioned in the comments in one of those? I don't know how that works exactly, but assuming apt ignores a list file after the Valid-Until date, I'd imagine it'd still be difficult to distinguish between the case of a repo that's simply not been updated vs one that's being MITM'd to give old data. (Also, I think all of these security concerns are pretty niche, but if we're going for niche cases, that's also one to account for). – muru Nov 06 '23 at 10:09
  • I’ve added a paragraph to discuss replay attacks. When apt queries a server with expired metadata, it warns about it (or perhaps even gives an error, I can’t remember), it doesn’t just ignore it. As you say it’s difficult to distinguish between an outdated mirror and a MITM replay attack, and while the effects are the same, being aware that one is under attack is useful. – Stephen Kitt Nov 06 '23 at 10:16
  • 1
    It's an error: https://unix.stackexchange.com/q/2544/70524 – muru Nov 06 '23 at 10:17
  • So you are still suggesting using TSL on apt? If so how? could put https in front of entries in sources.list work except for security.debian.org ? What is the best practice? Can you add it to the reply? thanks! – user3450548 Nov 06 '23 at 10:33
  • @user3450548 see the update. – Stephen Kitt Nov 06 '23 at 10:46