Docker-alpine: apk by default fetch package info via HTTP instead HTTPS

[danmx]

It'd be safer and more enterprise friendly if by default it used HTTPS

fetch http://alpine.gliderlabs.com/alpine/edge/main/x86_64/APKINDEX.tar.gz
fetch http://alpine.gliderlabs.com/alpine/edge/community/x86_64/APKINDEX.tar.gz

[andyshinn]

I'll raise this question with Fastly and see what options are available. They sponsor the CDN for a certain cost and SSL appears to be an additional cost item: https://docs.fastly.com/guides/securing-communications/ordering-a-paid-tls-option.

However, they do provide a shared SSL option. I enabled it and created https://alpine.global.ssl.fastly.net/alpine/. If people want to use this they could override the default /etc/apk/repositories file with something like:

sed -i 's/http\:\/\/dl-cdn.alpinelinux.org/https\:\/\/alpine.global.ssl.fastly.net/g' /etc/apk/repositories

[furikake]

How will modifying http://dl-cdn.alpinelinux.org to https://alpine.global.ssl.fastly.net impact downloads from http://alpine.gliderlabs.com?

Slightly off topic but it would be nice to protect the path from Fastly to your lighttpd origin server also. You could potentially use a free cert from https://letsencrypt.org/

[andyshinn]

http://dl-cdn.alpinelinux.org and http://alpine.gliderlabs.com are actually the same thing. The SSL domain covers both.

I believe the package indexes are provided by community members. So, I think to get origin SSL you should start an email thread on Alpine Linux infra list at https://lists.alpinelinux.org/alpine-infra/summary.html.

[furikake]

Thanks @andyshinn. Makes sense. I think I got confused as your repository file is different to mine. I can confirm that it works though:

gliderlabs/alpine:3.4 default /etc/apk/repositories

# cat /etc/apk/repositories
http://alpine.gliderlabs.com/alpine/v3.4/main
http://alpine.gliderlabs.com/alpine/v3.4/community

Modify as per @andyshinn's sed

# sed -i 's/http\:\/\/alpine.gliderlabs.com/https\:\/\/alpine.global.ssl.fastly.net/g' /etc/apk/repositories

Check the new /etc/apk/repositories file

# cat /etc/apk/repositories
https://alpine.global.ssl.fastly.net/alpine/v3.4/main
https://alpine.global.ssl.fastly.net/alpine/v3.4/community

Install something:

# apk add --update bash
fetch https://alpine.global.ssl.fastly.net/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch https://alpine.global.ssl.fastly.net/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
(1/5) Installing ncurses-terminfo-base (6.0-r7)
(2/5) Installing ncurses-terminfo (6.0-r7)
(3/5) Installing ncurses-libs (6.0-r7)
(4/5) Installing readline (6.3.008-r4)
(5/5) Installing bash (4.3.42-r3)
Executing bash-4.3.42-r3.post-install
Executing busybox-1.24.2-r9.trigger
OK: 13 MiB in 16 packages

I couldn't test against an intercepting proxy as I couldn't get http_proxy and https_proxy to be honoured. It is set correctly as curl seems to recognise it.

[michaelkruglos]

There's redirect from https to http when curling https://alpine.global.ssl.fastly.net/alpine/v3.5/main.

$ curl -v https://alpine.global.ssl.fastly.net/alpine/v3.5/main
*   Trying 151.101.128.249...
* TCP_NODELAY set
* Connected to alpine.global.ssl.fastly.net (151.101.128.249) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: a.ssl.fastly.net
* Server certificate: DigiCert SHA2 High Assurance Server CA
* Server certificate: DigiCert High Assurance EV Root CA
> GET /alpine/v3.5/main HTTP/1.1
> Host: alpine.global.ssl.fastly.net
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: http://dl-4.alpinelinux.org/alpine/v3.5/main/
< Server: lighttpd
< Via: 1.1 varnish
< Fastly-Debug-Digest: 9b79c0bf9ea9b97404b47a44b020533cba4a7d192a82d658c8229be58d26fefb
< Content-Length: 0
< Accept-Ranges: bytes
< Date: Sun, 21 May 2017 18:33:35 GMT
< Via: 1.1 varnish
< Age: 1740632
< Connection: keep-alive
< X-Served-By: cache-dfw1838-DFW, cache-hhn1539-HHN
< X-Cache: HIT, HIT
< X-Cache-Hits: 1, 3
< X-Timer: S1495391615.386802,VS0,VE0
<
* Curl_http_done: called premature == 0
* Connection #0 to host alpine.global.ssl.fastly.net left intact

[devdavidkarlsson]

Is this one still open?

apk --update upgrade &&     apk add curl ca-certificates &&     update-ca-certificates &&     rm -rf /var/cache/apk/*
---> Running in 5f5bcb261528
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.7/main: temporary error (try again later)
WARNING: Ignoring APKINDEX.70c88391.tar.gz: No such file or directory
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.7/community: temporary error (try again later)
WARNING: Ignoring APKINDEX.5022a8a2.tar.gz: No such file or directory
OK: 4 MiB in 11 packages
WARNING: Ignoring APKINDEX.70c88391.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.5022a8a2.tar.gz: No such file or directory
ERROR: unsatisfiable constraints:
 ca-certificates (missing):
....

[introllo]

Doesn't work behind a proxy:

$ docker run -it --rm --name test alpine:latest /bin/ash
/# export http_proxy=http://proxy.server.com
/# apk update // <-- this works
/# unset http_proxy
/# export https_proxy=http://secure-proxy.server.com
/# sed -i 's/http\:\/\/dl-cdn.alpinelinux.org/https\:\/\/alpine.global.ssl.fastly.net/g' /etc/apk/repositories
/# apk update // <-- this fails

(NOTE: my proxy does not require authentication)

[mkj28]

@andyshinn +1 to switch to https for all. Maybe we can sponsor the SSL CDN? How much traffic do you estimate for this?

[tsuna]

The Remote Code Execution in Alpine Linux reported recently wouldn't be as bad if packages were fetched via a secure channel.

[underyx]

We might also be interested in sponsoring TLS. @andyshinn do you have an estimate of the cost?

[razor-x]

It's a bit crazy in my opinion that Alpine is widely used (and recommended) in production and CI environments in major enterprises and they are all vulnerable to man-in-the middle attacks on core packages like git and ssl because the package repo is served over http.

This issue should be consider a critical security vulnerability but is stalled after 2+ years at this point. If cost is a issue can't we just use CloudFlare free SSL, a page rule for the redirect, and be done with it?

[uberspot]

After this https://justi.cz/security/2019/01/22/apt-rce.html this issue is again very relevant.

[am11]

Has it been posted to some upstream official channel (https://bugs.alpinelinux.org/projects/alpine-infra/issues, [email protected], [email protected] etc.)? If so, could you please share a permalink?
Community might also be willing to contribute in sharing CDN-with-TLS cost, as more folks appear to be using Alpine in production workloads these days.

[chetanmeh]

On one of the issues in alpinelinux

apk checks downloaded packages using repository public keys, so it shouldn't really matter much. If you insist on using HTTPS, you could use a mirror supporting it directly, without using the Fastly CDN. All this considered, using HTTP for this will have no impact on security. It will only avoid the cost of encryption introduced by SSL.

[mwarkentin]

We started getting 301 Permanent redirects from http://alpine.gliderlabs.com to https://alpine.gliderlabs.com which was breaking our package installs. Anyone else run into this?

We moved over to https://alpine.global.ssl.fastly.net which seems to be working so far.

[rvillane]

we also ran into this HTTP issue, looking forward for an update

[fiesh]

It seems that this was changed, at least in alpine's official docker images, from 3.12 to 3.13.

Please let me stress that https is the wrong protocol here. People bringing up CI pipelines bring up good points why it should be http! You very well might want to have a caching proxy installed. Using https adds no security at all. This is an anti feature and should be reverted to http.

[AndreKoepke]

HTTPS is never a "anti feature". It is a transport-encryption, so you can be sure, that a attacker don't change packages to some infected content. Imagine, that a attacker place bad content, that you are using in your CI-system. In a worst case, you shipping out infected software.
Yes, there a lot caching proxies, but they need a secure upstream too.

Unencrypted HTTP should be avoided (as it already happen slowly in the webbrowsers). Only in intern environments is HTTP it is "okay", but should be deprecated (in case that a attacker is inside of a local network).

[fiesh]

Sorry, but I think you misunderstand the issue. There are two concepts playing here, _integrity_ and _confidentiality_, and you seem to confuse them.

What you want for a download as such is integrity, NOT confidentiality. However:

• https provides confidentiality.
• https does NOT provide integrity.
• http provides neither confidentiality nor integrity.
• Only chains of trust by other means, checksumming in this case, provides integrity, irrespective of the transport being http or https.
• People should properly understand these concepts and not jump to wrong conclusions. This is dangerous since they seem to believe a chain of trust becomes superfluous when https is used, which is just wrong.

(Believing that https will protect you against shipping "infected software" is a prime example of a dangerous misunderstanding.)

[ncopa]

I'm closing this. Official alpine images move to https://github.com/alpinelinux/docker-alpine

Also, main reason for moving to https was that it "solved" some network issues for some users, which I suspect was related to intercepting proxies. The integrity checking is done via the apk signing so the transport does not really matter that much.