From nobody Fri Mar 29 02:01:02 2024 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 5E1C4DCB54D for ; Mon, 22 Feb 2016 13:16:19 +0000 (UTC) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id 8E576DD0685 for ; Mon, 22 Feb 2016 13:16:16 +0000 (UTC) Received: by mail-wm0-f52.google.com with SMTP id b205so155065796wmb.1 for ; Mon, 22 Feb 2016 05:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LhpyXfbpIUMXUT90KNak40keGJWAVg7eZtXDZAXLWdk=; b=h24gX2UMTzONrsnIvzvpdw7+GLG8Gm4x5zbruIFX98hlivOo5icCAdsF2uV15+YWYA Kj5SZsuuN5OQzpyJV3yqUdXXXsGp27mqOOVAh+b2IyPHwp7cmxSEjt6s8IA0nw3MmMQl rVWe3jwxgNcHhDVII52qKdL30gNcR5qdem4hB1rqesTsKzZGhx1sVvn94wxMvxARVGO6 GC7nMYRayCeWY6ZYtMC3eIzoE9WS0k83DyLH99NsmysPEi/kcSyR83desd4Ou5OyI/MH JiT5wZgkBM0fKcAMqLOGacmEUAUEcaECMALa9sGva8oRlasw9f3xRZmHmyfGCoWF7vwV FKFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=LhpyXfbpIUMXUT90KNak40keGJWAVg7eZtXDZAXLWdk=; b=WrJiW7mlDpaXjy36SIF78gr42oP89C2IFPtSctjj4y3CN97I+N5QOdBfKvB/GVPFpa 0fd5FlQfKz+kn9/9BFs7nS/D9Ow5xt3V6MhF3mFh2eStZhWM8EEDKyzdinz4kJhPyhOD LFgJhcP5XesYs4/X9z49RJku722sCz63hAcQ2TXouxwqAseNGRFi37OKwWHFNzAF1Z/K q6VoMIQhUo4G/Vb9wVkjNzhSLepQsYvSotZ2JFat/8K/i5fi9byImwEhQWh1ybh469iD G8lxbN/S7gV7rIH0nL/MkplUfq/rpAWTzUh23ei2hsSc/OCZoaf4jX2xQRrPTApz931v WOfw== X-Gm-Message-State: AG10YOTYhV/oI8Qyx8sQA4+kkpC0zIEHWaSzxAVzK5UzyfGKk2py6P+GS1Lw0nHztgmYwYdiMG5bubxy1gsrYg== X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 X-Received: by 10.28.59.212 with SMTP id i203mr11796571wma.69.1456146973233; Mon, 22 Feb 2016 05:16:13 -0800 (PST) Received: by 10.27.177.154 with HTTP; Mon, 22 Feb 2016 05:16:13 -0800 (PST) Date: Mon, 22 Feb 2016 10:16:13 -0300 Message-ID: Subject: [alpine-devel] What could be done to make Alpine distribution more secure From: Alba Pompeo To: alpine-devel@lists.alpinelinux.org Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: ClamAV using ClamSMTP A few days ago Linux Mint's website was hacked and their ISOs were replaced with backdoored images. This is a great security concern and I think a good opportunity for Alpine Linux to rethink its distributions of ISOs and what could be improved. I'll start with the obvious HTTPS support. The download links on http://www.alpinelinux.org/downloads/ all point to a HTTP link. If you try to manually change it to HTTPS you get the message - wiki.alpinelinux.org uses an invalid security certificate. The certificate is only valid for the following names: mail.alpinelinux.org, alpinelinux.org The certificate expired on 05/17/15 06:04. The current time is 02/22/16 14:11. (Error code: ssl_error_bad_cert_domain) And alpinelinux.org also doesn't go to HTTPS by default even with HTTPS Everywhere installed. Shouldn't it always be preferred? What else can you think about that would make alpine distribution more secure? The most advanced security feature I've seen a few distributions doing is reproducible builds, but it appears to be very hard and maybe not a priority right now. But for the future maybe it could be an idea. Ciao. --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Fri Mar 29 02:01:02 2024 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 C0A39DC5D95 for ; Tue, 23 Feb 2016 05:13:51 +0000 (UTC) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id 8D382DC00A7 for ; Tue, 23 Feb 2016 05:13:51 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id fy10so103553910pac.1 for ; Mon, 22 Feb 2016 21:13:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=IM50kJOAFipRYBnkBIWKVI6b5JCKD7qDqvYCG3oCoq0=; b=C7ba2HTCb6f1iQ4QKMEZgjuZp0l6EO+6ut/4KVSHnlTqDdId4P3aWgE4p5UtyFePVS YDe6RmJc/om09+aV5wklHRePvokF1iKHLdYqoNlts/VZbmpijOW4lf3gzxSOesj8qPUv oVoWone4nP9jl3C+cbgZGjHQe7nkkXR8F3hLn3b4QfSk2rpN3JzbdKFl/llXoYIEeeIB JV032xsAe+f8x31PRZf0gCnrtaoXfHLLkUsktEA6HN2g43KwQGsqkr49fvW4ESQQPnhP NrAZnAb1qC4WpQfkhqvCT2Ojsc7SNL2O2UxZzbOYAn8YE7iqZ7lQ7pcSlumZGODZLQfp fcKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=IM50kJOAFipRYBnkBIWKVI6b5JCKD7qDqvYCG3oCoq0=; b=mFVVd2M2dmId+hteCnLsZvilxZOt6WJNNsE+h+lzuhJe9aYON3cU2QWfuD6sspqGYk IfZfWMNvz5HSubctB+ecLeZO/g9mqd0/p1EJLDTgkzlVKti77BoxOB2CIKvkWORS3ZWB zda2wdgnKnXMNG44Lan+c7ubNUpb7qBpe8bNDpvNe9yr2dv5n/s1s+IWPi2/c/c0CQ45 rgEDkpuReoSpdk4HENEX63iGvbrb4AOsSWYdDLpH11egoF17yI8WVTJuRY0QZygdJHFL mNNd5AGceQaky7oQMJMPqWdpF2izvPK3zRiLWT7u+moU4WmXSlPomHc/t8FLxW/qRIz4 v6bw== X-Gm-Message-State: AG10YOSr2L9ZTAO2B/2B2VVU3vlkecjQcX1ux9ivyDn81TXMIdx4crensfvEtGIQtSJv4w== X-Received: by 10.67.12.175 with SMTP id er15mr43290330pad.70.1456204430040; Mon, 22 Feb 2016 21:13:50 -0800 (PST) Received: from newbook ([50.0.225.136]) by smtp.gmail.com with ESMTPSA id dg1sm40730114pad.18.2016.02.22.21.13.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Feb 2016 21:13:49 -0800 (PST) Date: Mon, 22 Feb 2016 21:13:45 -0800 From: Isaac Dunham To: Alba Pompeo Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] What could be done to make Alpine distribution more secure Message-ID: <20160223051344.GA4173@newbook> References: 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-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Feb 22, 2016 at 10:16:13AM -0300, Alba Pompeo wrote: > A few days ago Linux Mint's website was hacked and their ISOs were > replaced with backdoored images. The most obvious precaution for this is -sign the images -checksum the images (ideally, sha256/sha512 and md5) -sign the checksums -include checksums and signatures in the release announcements -have a link to a separately administered archive containing the announcement; you want some place that would have to be compromised separately. (ie, if there's a gmane archive, link there) > This is a great security concern and I think a good opportunity for > Alpine Linux to rethink its distributions of ISOs and what could be > improved. > I'll start with the obvious HTTPS support. The download links on > http://www.alpinelinux.org/downloads/ all point to a HTTP link. > If you try to manually change it to HTTPS you get the message - > wiki.alpinelinux.org uses an invalid security certificate. HTTPS downloads will add to the CPU load, without preventing the typical hacks. It prevents MITM attacks when endpoint attacks are typical. Checksums and signatures should be available over HTTPS, though. (The security benefit proportional to the cost is greater.) > What else can you think about that would make alpine distribution more secure? > The most advanced security feature I've seen a few distributions doing > is reproducible builds, but it appears to be very hard and maybe not a > priority right now. But for the future maybe it could be an idea. Reproducible builds are not as hard as you'd think (says someone who spent a few years poking at Debian packages, which were almost fully reproducible before anyone got into that). The fundamental requirements are: -there must be a fully deterministic set of packages installed, if the build can vary based on installed packages. Solution: use minimal autobuilders, like Debian and Alpine do -the configuration should be overspecified, not underspecified Solution: write out the config options longhand, rather than relying on defaults. (We're partway there.) This is important for cross-compiling, anyhow. -the build options (optimization, hardening, and linker flags) must be deterministic. Solution: specify them in the build scripts and in systemwide, distro-provided config files, like Debian and Alpine do. -the build ID, if provided, should correspond to the source and options, rather than varying with the path in which it was compiled. This is just a few bytes that can vary. Solutions: (a) don't build with debug flags, since gcc encodes the path to the source in the debug information, making the object files have a variable checksum. (True of some packages, but far from all.) (b) between prepare and build, come up with a checksum based on the build options and the source code checksums. For example: BUILDID=`{ find -type f -o -type l -exec shasum '{}' + echo "$CC $CXX $CFLAGS $CXXFLAGS $CPPFLAGS $LDFLAGS } | sha512sum |cut -c -128` -there should be no way to circumvent the rules for build environment Solution: use a build server instead of package uploads, like Alpine does. In other words: Other than the build-id, it should be possible to reproduce Alpine packages. And if you set up an autobuilder per the standard directions, it should be fully reproducible. Now, as far as running from r/o media goes (another possibility that was mentioned) -this doesn't prevent hacks, but only prevents adding permanent backdoors. -this does prevent security updates without physical presence -a 'cheap' halfway measure would be bind-mounting every path that's only rarely written to over itself, but readonly. This doesn't prevent someone who has a root shell from writing, but it does prevent someone from exploiting symlink attacks or other ways of writing to arbitrary files without shell access. Example: ROPATHS="/usr /lib /bin /sbin /boot /etc /var/www/isos" for DIR in $ROPATHS; do mount -o bind,ro $DIR $DIR; done # ... do stuff ... for DIR in $ROPATHS; do umount $DIR; done apk update apk upgrade for DIR in $ROPATHS; do mount -o bind,ro $DIR $DIR; done Note that a few scripts may need adjustment to work with RO /etc. Thanks, Isaac Dunham --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Fri Mar 29 02:01:02 2024 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 CBCF7DD0D1A for ; Mon, 22 Feb 2016 14:00:50 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id 56A5EDD0D14 for ; Mon, 22 Feb 2016 14:00:47 +0000 (UTC) Received: from idefix.lespocky.dyndns.org ([146.52.74.183]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0LtzWQ-1Zqe5f1cow-011WEA for ; Mon, 22 Feb 2016 15:00:41 +0100 Received: from idefix.lespocky.dyndns.org ([10.182.63.91]) by idefix.lespocky.dyndns.org with esmtpa (Exim 4.82) (envelope-from ) id 1aXr2T-0001sA-E2 for alpine-devel@lists.alpinelinux.org; Mon, 22 Feb 2016 15:00:39 +0100 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="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 22 Feb 2016 15:00:37 +0100 From: Alexander Dahl To: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] What could be done to make Alpine distribution more secure In-Reply-To: References: Message-ID: X-Sender: post@lespocky.de User-Agent: Roundcube Webmail/1.1.4 X-Scan-Signature: 39a5d6fc02690a1c7b2cfbf1a9afee86 X-Spam-Score: -4.1 (----) X-Provags-ID: V03:K0:4SX6VUgxXJlxhNK0GRHHwpXOyBBhp3r1NI7U06WfTakNSOru9Mw mAWUjEYruYanaQ6T1QOedwwoQy/p632PZi7vQw33/LL584b/MVucruNUUMMG9466Z0nmPiE 5qsCkhKkfdiVHgYMkjYeE/ukRjJhnDOBS0/bPREtoaCUlBtEnsYqq6zGKvAYfXtr7lynapO MUAp6SpR1/5/izOPIbUVg== X-UI-Out-Filterresults: notjunk:1;V01:K0:jURJ5cPAgx0=:QebRKMEpFvOmSFoHIx7Ky8 hRsvYSVLw/Jd2JSw3ieRVg1Ym+JIIKV997qF+fXEWXCZTMFPJ5Y+27La+kPmfP4LBcWCVYp9M psO2bZzreF5CXM4gnOK3Pcbd2DinnE3micNGMSysYegF1oYEaqiUpg2funDfeBPQT7VQGtU/p CJKJDReQV8YdGI1FssSJWJhWLkiGbafWBK2IqrZmy6kDrV00e82+jU8oFA4EAr0G+PChwEdMr 5Mp1mXCOMzHdqwv8lr0a8xkzvrQu4pyxcEXttWwpTt4XF7IXynnKUFpnA8Xt/QzgWNeifnnfI VdMB+V0ZozfVGy+myAeRwexyLEbEbyRwGp+BoUpRUErIAoysHGG+9xXF6NBeD2Uf+Kja0hX8j JcfjN0/mQkg+Z0F9bbxn3WIpc/QrTvM1P1HAD1PUWlKl6rAWHLlanaWMEejxG2Es8FKhvo8QF /XE9GRL8D4fZheTYXRLjr0sOoebFHLFLTGsTmSJEa2s5pnFwJPM5jSpVqtR9D4o4Wt+vhRpuQ mc2RYvrAii7AHDP9lzjPoqDQLI8swp1TwxBR5enBPD552jzdmflgjCtU45ms/cd1sB32PLm9s W9Rw+uyZQ1R4sSP7s+c2DiVlkVnxMk2nbmWC5LU8vDFc8g0lUUYYNE7TZpDSXNak3u3JIWx7a BO6kSLYej8DR6Dy5QKHBTVR5lrHSmxIffOe7nXJR1qohOSoBjf1ja2+tBFffJdWUA474JfQoR TCCER8cNWNnJjYP8 X-Virus-Scanned: ClamAV using ClamSMTP SGVpIGhlaSwgDQoNCkFtIDIwMTYtMDItMjIgMTQ6MTYsIHNjaHJpZWIgQWxiYSBQb21wZW86DQo+ IFdoYXQgZWxzZSBjYW4geW91IHRoaW5rIGFib3V0IHRoYXQgd291bGQgbWFrZSBhbHBpbmUgZGlz dHJpYnV0aW9uIG1vcmUgc2VjdXJlPw0KDQpPbmUgdGhpbmcgYmV0dGVyIHRoYW4gd2l0aCBMaW51 eCBNaW50IGlzIGFscmVhZHkgcHJlc2VudDogUEdQIHNpZ25lZA0KaW1hZ2VzLiBUaGlzIHdvdWxk IGJlIGV2ZW4gYmV0dGVyIGlmIHRoZSBzaWduaW5nIGtleSBoYWQgc29tZSBtb3JlDQp0cnVzdHdv cnRoeSBzaWduYXR1cmVzLCBidXQgaXQncyBhIHN0YXJ0LiA6LSkNCg0KR3JlZXRzDQpBbGV4DQoN Ci0tIA0KwrtXaXRoIHRoZSBmaXJzdCBsaW5rLCB0aGUgY2hhaW4gaXMgZm9yZ2VkLiBUaGUgZmly c3Qgc3BlZWNoIGNlbnN1cmVkLA0KdGhlIGZpcnN0IHRob3VnaHQgZm9yYmlkZGVuLCB0aGUgZmly c3QgZnJlZWRvbSBkZW5pZWQsIGNoYWlucyB1cyBhbGwNCmlycmV2b2NhYmx5LsKrIChKZWFuLUx1 YyBQaWNhcmQsIHF1b3RpbmcgSnVkZ2UgQWFyb24gU2F0aWUpDQoqKiogR251UEctRlA6IEMyOEUg RTZCOSAwMjYzIDk1Q0YgOEZBRiAgMDhGQSAzNEFEIENEMDAgNzIyMSA1Q0M2ICoqKg0KDQoNCi0t LQ0KVW5zdWJzY3JpYmU6ICBhbHBpbmUtZGV2ZWwrdW5zdWJzY3JpYmVAbGlzdHMuYWxwaW5lbGlu dXgub3JnDQpIZWxwOiAgICAgICAgIGFscGluZS1kZXZlbCtoZWxwQGxpc3RzLmFscGluZWxpbnV4 Lm9yZw0KLS0tDQo= From nobody Fri Mar 29 02:01:02 2024 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 B26AFDC04DD for ; Tue, 23 Feb 2016 09:59:46 +0000 (UTC) Received: from newmail.tetrasec.net (unknown [74.117.189.116]) by mail.alpinelinux.org (Postfix) with ESMTP id 87E0FDC012C for ; Tue, 23 Feb 2016 09:59:46 +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 2D1235A0882; Tue, 23 Feb 2016 09:59:44 +0000 (GMT) Date: Tue, 23 Feb 2016 10:59:39 +0100 From: Natanael Copa To: Alexander Dahl Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] What could be done to make Alpine distribution more secure Message-ID: <20160223105939.33421716@ncopa-desktop.alpinelinux.org> In-Reply-To: References: 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 15:00:37 +0100 Alexander Dahl wrote: > Hei hei, > > Am 2016-02-22 14:16, schrieb Alba Pompeo: > > What else can you think about that would make alpine distribution more secure? > > One thing better than with Linux Mint is already present: PGP signed > images. This would be even better if the signing key had some more > trustworthy signatures, but it's a start. :-) At least you know it is the same person who make every release. (or someone who has access to the private keys) -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Fri Mar 29 02:01:02 2024 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 4A13EDC1B88 for ; Mon, 22 Feb 2016 18:20:00 +0000 (UTC) Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id 8E4D4DC0D58 for ; Mon, 22 Feb 2016 18:19:58 +0000 (UTC) Received: from mail-in-14-z2.arcor-online.net (mail-in-14-z2.arcor-online.net [151.189.8.31]) by mx.arcor.de (Postfix) with ESMTP id 3q8Bcr36KGz8RwF; Mon, 22 Feb 2016 19:19:56 +0100 (CET) Received: from mail-in-17.arcor-online.net (mail-in-17.arcor-online.net [151.189.21.57]) by mail-in-14-z2.arcor-online.net (Postfix) with ESMTP id 657EF209C0B; Mon, 22 Feb 2016 19:19:56 +0100 (CET) X-Greylist: Passed host: 213.182.249.19 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-17.arcor-online.net 3q8Bcr1lPnzYZn DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1456165196; bh=TkeqbQvGm5ELHjoOIM7ewF2VuoKcaH8VMVtdemFArZM=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=m9nOl8UqoZlPVze+93qCrEorFR4XLwr8dKN0kVDvlEmrdrzExTMWmAr+x7cBvYmxe ZWtwE0b/LHtbLAetSaHxnutpvzdaeW8mTC+H6Eor0fpfot+dis2yODtH6UyB58aqaH O80+F/DXLYgSCnJjWmagf3HBADy/ATHKMBQGFEtg= X-Greylist: Passed host: 213.182.249.19 Received: from [192.168.101.128] (unknown [213.182.249.19]) (Authenticated sender: panthera.tigris@arcor.de) by mail-in-17.arcor-online.net (Postfix) with ESMTPA id 3q8Bcr1lPnzYZn; Mon, 22 Feb 2016 19:19:55 +0100 (CET) Subject: Re: [alpine-devel] What could be done to make Alpine distribution more secure To: Alba Pompeo , alpine-devel@lists.alpinelinux.org References: From: Der Tiger X-Enigmail-Draft-Status: N1110 Message-ID: <56CB514A.3060402@arcor.de> Date: Mon, 22 Feb 2016 19:19:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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. > 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. > 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. Regards, Tiger --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Fri Mar 29 02:01:02 2024 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 ---