X-Original-To: alpine-devel@mail.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from mail.alpinelinux.org (dallas-a1.alpinelinux.org [127.0.0.1]) by mail.alpinelinux.org (Postfix) with ESMTP id 4CCBCDD082E for ; Tue, 23 Feb 2016 10:03:00 +0000 (UTC) Received: from newmail.tetrasec.net (unknown [74.117.189.116]) by mail.alpinelinux.org (Postfix) with ESMTP id 05354DC6DB0 for ; Tue, 23 Feb 2016 10:02:59 +0000 (UTC) Received: from ncopa-desktop.alpinelinux.org (103.63.200.37.customer.cdi.no [37.200.63.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by newmail.tetrasec.net (Postfix) with ESMTPSA id 172855A0882; Tue, 23 Feb 2016 10:02:57 +0000 (GMT) Date: Tue, 23 Feb 2016 11:02:53 +0100 From: Natanael Copa To: Der Tiger Cc: Alba Pompeo , alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] What could be done to make Alpine distribution more secure Message-ID: <20160223110253.57ffce2c@ncopa-desktop.alpinelinux.org> In-Reply-To: <56CB514A.3060402@arcor.de> References: <56CB514A.3060402@arcor.de> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.28; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP On Mon, 22 Feb 2016 19:19:54 +0100 Der Tiger wrote: > Hi Alba, > > > I'll start with the obvious HTTPS support. The download links on > > http://www.alpinelinux.org/downloads/ all point to a HTTP link. > Going SSL won't give the downloader any relevant additional security, > since the connection between the server and the downloading client isn't > a likely point of attack. Such a Man in the Middle attack is far too > much effort only to corrupt the transferred ISO image. It is much easier > to take the same approach the Mint hackers took, and attack the website, > directly. SSL won't help your there. > > To make the website hacking-proof, the entire content would have to be > on a physically read-only medium (e.g. DVD-R), but I doubt any admin to > be willing to handle such hassle. We don't use any web application server for main website. It is generated static pages. So you will not be able to exploit some wordpress vulnerability to hack the site. > > The certificate is only valid for the following names: > > mail.alpinelinux.org, alpinelinux.org > The Alpine website uses several sub-domains and the certificate would > therefore have to be a wildcard certificate in order to be valid on all > sub-levels. Those wildcard certificates are considerably more expensive > than any generic certificate. letsencrypt might be an option. > > HTTPS Everywhere installed. Shouldn't it always be preferred? > Only, if you can trust the server certificate and you want to transfer > data, that would give any listener valuable information. SSL does > neither hide your IP address, nor your connection state. Surfing the > Alpine website and downloading an Alpine ISO hardly counts as valuable > information. > > SSL only hides (too some degree) the information inside the connection, > but not the connection itself. To accomplish a fully encrypted > connection, you need tools like VPN. Furthermore, most certificates can > be faked, spoofed and even most certificate authorities (CA) are not to > be trusted, if it comes to critical data. The entire certificate system > has already collapsed due to the system requiring all CAs to be > trustworthy. If one CA fails, the entire system falls apart. And today, > there are more untrustworthy CAs than trustworthy ones. > > Offering checksums to every downloaded file does only verify the file's > consistency with the original file, but does not prevent any tampering > with the files stored on the server. Because, lets face it, if someone > is able to hack the website and replaces the downloadable files, he/she > is certainly qualified to modify the online displayed checksums, > accordingly. > > The only way known to me to ensure the file contents validity is to > offline encrypt the file with a private key and hardcode the public > de-cryption key into the static part of the website. Any modifications > to the file alone lets the de-cryption fail, while the public key can't > be modified without locally accessing the web sever. We cryptographically sign the content of every package (public keys are in /etc/apk/keys). So we do verify that the package content is not tampered with. If you also check the pgp signature of the iso image, then you can be relatively sure that the content you get is the the same as was generated on the build servers, regardless if you get it over encrypted transport or not. -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---