The reasoning wasn't complete. The packages are signed using this key
belonging to Natanael, right?
So to bootstrap trust, I suppose this key is trusted by default in the
ISO images, right? And so the engineer must download the ISO image
using HTTP over TLS to gain some confidence the website and public key
that is presented there is legit. Still, the TLS configuration of the
website is suboptimal, see
E.g., it is not configured to provide HSTS headers to close the loop
(i.e., initial visits to https://www.alpinelinux.org
could still be
I personally use Alpine Linux from the official Docker images, which
are minimal in size. I'm not entirely sure what integrity assurances
can be given about the whole chain from official release of software
(I suppose, by Natanael) to Docker build is?
Very interested in your thoughts about this.
On Thu, Mar 24, 2016 at 7:09 PM, Sander Maijers <s.n.maijers_at_gmail.com> wrote:
> Hi all,
> I've noticed that the Alpine Linux packages mirrors URLs all have the
> http scheme instead of https.
> Apparently, the alpinelinux.org DNS zone is not signed either.
> Packages are being signed for some time though.
> If this is correct, then I think an attacker should be able set up a
> fake packages mirror with matching signatures, and trick targets into
> resolving well-known Alpine Linux packages mirrors to this fake
> mirror. This leads me to conclude that a man-in-the-middle attack
> against the Alpine Linux package mirrors is a feasible way to plant
> backdoors into Alpine Linux hosts that undergo `apk add`.
> A quick and free solution would be to use e.g. Let's Encrypt to
> generate valid TLS certificates for all mirrors,
> and additionally DNSSEC-signing alpinelinux.org would bring some
> further reassurance (e.g., also for non-HTTP traffic).
> This is not unusual. It appears that Red Hat does see the value of
> distributing both package metadata and data via HTTP over TLS.
Received on Thu Mar 24 2016 - 19:30:31 GMT