31

As far as I know, HTTP is prone to man-in-the-middle attacks. As such, the repositories in Alpine Linux or the CentOS Mirrors are not HTTPS.

In the olden days, having HTTPS used to be an expensive matter. It cost server CPU time and the certificates weren't free. But it’s 2022 now, and we have plenty of ways to overcome those problems and security has been top priority than ever!

How can we obtain binaries smarter?

Also is this a problem in the wider Linux community? I.e., Ubuntu, Linux Mint, openSUSE, etc.?

4
  • 2
  • 2
    Many CentOS mirrors are both HTTP and HTTPS (and all CentOS 9 Stream mirrors are both), so just pick an HTTPS one to use.
    – Randall
    Jan 9, 2022 at 19:28
  • If the mirrors required credentials over HTTP and you comply and/or you are not verifying the checksum after downloading then you might not be the target audience for CentOS.
    – MonkeyZeus
    Jan 10, 2022 at 19:23
  • @Randall Since OP mentions Ubuntu as well, a lot of Ubuntu mirrors are unfortunately HTTP-only. I can't use them because my ISP runs (well-intended?) virus scans on all HTTP traffic and often blocks certain packages as false-positive.
    – AndreKR
    Jan 11, 2022 at 16:37

6 Answers 6

38

The packages are indeed signed, hence a manipulation would be noticed.

Also the packages are not secret, so there isn't any need to encrypt them on the transfer.

With the mass of downloads from mirrors, this probably saves them a lot of resources.

It is the same on Debian and Ubuntu.

13
  • 14
    It is doubtful that "this probably saves them a lot of resources" istlsfastyet.com Jan 9, 2022 at 4:55
  • 1
    Plus for users in (and using the network of) a business, school or other organization that inspects network traffic, such inspection is transparent for HTTP, but HTTPS must be decrypted then re-encrypted with a different certificate which client software probably doesn't recognize, making system maintenance fail, which is typically bad. Jan 9, 2022 at 5:13
  • 11
    Traffic analysis is a nice tool to discover what a server is installing, and thus what potentially vulnerable packages its pulling - so I disagree with your assertion that “the packages are not secret so no need to encrypt them”.
    – Moo
    Jan 9, 2022 at 9:05
  • 6
    @AndrewSavinykh AES CPU time is not the only thing that increases resources. https being inherently anti MITM makes it impossible for http acceleration proxies to reduce the server load. HTTP accelerators like Squid.
    – Aron
    Jan 10, 2022 at 4:36
  • 1
    @moo I have read before that traffic analysis still allows you to know what is downloaded with https since you can observe the size of the download, and it's not secret. Maybe you can't differentiate packages by weight in every case, but you can make assumptions (if you installed 3 php modules, the next one is more likely another module than a Paint program if I doubt between those 2)
    – Einacio
    Jan 10, 2022 at 14:04
22

From a technical perspective the fact plain HTTP content can easily be cached by proxy servers can make quite a bit of difference when you need to manage and update more than a handful of systems.

Setting up local mirrors is often overkill and not practical, but when your proxy server can serve updates from a cache at LAN speeds, rather than every client in your network connecting to an online source...

3
  • I'd rather have a local mirror at 10Mb/s than a remote mirror at 9600bps.
    – mckenzm
    Jan 10, 2022 at 13:48
  • Is something missing at the end? E.g., the implied not overkill is not that clear. Jan 11, 2022 at 12:47
  • HTTP Caching is interesting. That definitely helps with edge-servers and fast downloads to the client machines. However don't you think at-least the keys should be securely transmitted? Otherwise manipulation in both ends (hard, but possible in my view) would cause malicious packages to be distributed. Don't you think?
    – MaduKan
    Mar 26, 2023 at 4:17
15

The packages are signed by an off-channel method (GPG keys stored on your system).

The main use of having HTTP is to make it easy to have a dependency proxy between the Internet and your machines, which can save a lot of bandwidth and time by only having to download once (the first time) upgrades for potentially 1000s of (virtual) machines.

HTTPS prevents it (not completely, but makes it harder), because being end-to-end encrypted, you can't easily put something that'd intercept the downloaded packages to store them and serve them later.

2

Lots of mirrors will reply on HTTPS if you change the URL, even if the link to them is only HTTP. Using this is better than not verifying anything at all, but puts absolute trust in the mirror host. Using the official GPG signatures to verify the downloads leaves the trust with only parties you already trust completely.

If you follow the instructions here, you only need to trust the certificate for canonical.com, for example. https://ubuntu.com/tutorials/how-to-verify-ubuntu

2

A system time error could cause issues with HTTPS. It is not a real issue, but it is sometimes unnecessary.

An out of date system that don't have trusted certificates is a pain to get them updated.

Mirrors that need to respond to the same anycasted hostname.

It takes time to set up distributed mirrors with valid certificates.

1

CentOS distribution uses GPG to sign both rpm packages and yum/dnf repository metadata, so that MITM attack will be prevented.

See also How Fedora Secures Package Delivery, which is discussing Fedora, but package and repository metadata security tooling and policy is the same.

You must log in to answer this question.

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