From owner-freebsd-security@freebsd.org Sat Sep 19 03:48:34 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C02F8A0358B for ; Sat, 19 Sep 2015 03:48:34 +0000 (UTC) (envelope-from milios@ccsys.com) Received: from cargobay.net (cargobay.net [198.178.123.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 822C71440 for ; Sat, 19 Sep 2015 03:48:34 +0000 (UTC) (envelope-from milios@ccsys.com) Received: from [192.168.0.4] (cblmdm72-240-160-19.buckeyecom.net [72.240.160.19]) by cargobay.net (Postfix) with ESMTPSA id 477BEB53; Sat, 19 Sep 2015 03:43:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: HTTPS on freebsd.org, git, reproducible builds From: "Chad J. Milios" X-Mailer: iPhone Mail (13A344) In-Reply-To: <201509181444.IAA15072@mail.lariat.net> Date: Fri, 18 Sep 2015 23:48:27 -0400 Cc: Ben Bailess , freebsd-security@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7BAECC2B-5001-47D6-9199-8549697E7807@spam.lifeforms.nl> <201509181444.IAA15072@mail.lariat.net> To: Brett Glass X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 03:48:34 -0000 > On Sep 18, 2015, at 10:44 AM, Brett Glass wrote: >=20 > At 08:07 AM 9/18/2015, Ben Bailess wrote: >=20 >> I have to echo this sentiment -- authentication is important, and so is >> integrity. HTTPS would provide both -- to be sure you're talking to the >> "real" FreeBSD and give you confidence that your page content has not bee= n >> altered in transit by a network adversary (e.g. if you are using Tor)*. >=20 > I'd mainly be concerned about downloads of distros or updates being > tampered with. Worms are appearing that infect not only PCs but also > routers (e.g. the "Moon" worm, which affected most Linksys models availabl= e > at the time), setting up a perfect scenario for an MITM attack that could > substitute an infected file AND a forged checksum for the originals. If > an HTTPS download site were available, I would absolutely prefer it to > an HTTP one. Just my $0.02 USD. >=20 > --Brett Glass=20 We have HTTPS and its benefits even if you've downloaded via insecure FTP. S= ee https://www.freebsd.org/releases/10.2R/CHECKSUM.SHA256-FreeBSD-10.2-RELEA= SE-amd64.asc and the rest of the links found on https://www.freebsd.org/rele= ases/10.2R/signatures.html or https://www.freebsd.org/releases/9.3R/signatur= es.html How did this topic of the conversation start? Because http://freebsd.org doe= sn't issue a redirect to https://? Such a thing does not increase security, i= t only obscures the fact the user came in through http. HSTS, HPKP and even D= ANE are all non-solutions to this and related problems, or half-solutions at= best, if you ask me. Beyond the quasi-security of HTTPS more important is the security we get fro= m PGP with its web of trust as well as the multitude of public key servers i= n various jurisdictions worldwide. If security is what you're after, diligence will always be part of the cost.= I'm not against the layering of additional security, but to believe HTTPS i= s a one stop security shop, a silver bullet for confidentiality or integrity= , is a complacent mindset. I may be missing the boat as to the concerns you're having. I don't purport t= o know the ins and outs of freebsd-update or the binary pkg repos since, bes= ides the occasional download of a full release ISO, I've been building all e= lse from source for a long time and I'm stuck in my ways. I will say this though: I can't seem to find the svn server key fingerprints= signed by anything [useful] (even if you count the FreeBSD web site) becaus= e I only find the web servers' keys signed by a random one of the thousands o= f [as far as I'm concerned, untrustworthy] certificate authorities. I see me= rit in additionally having a secteam PGP signature over all fingerprints of r= elevant https keys in use, made available at a convenient location, even if i= t's only at the very web servers it's signing.=20 The secteam's public PGP key has proliferated across the globe for many year= s now and it's next to impossible to replace that without raising the alarm o= f someone exercising a modicum of diligence. HTTPS on the other hand, how it= is implemented and typically used, will betray you right under your nose an= d mislead you right to your face. You need both of course because without HT= TPS (or TLS in general and really the hierarchy of anointed CAs) you can't t= alk to any PGP key severs with any reasonable assurance. You really should get the secteam's PGP key and assure it's identical from a= s many varied sources as is prudent for your threat model. It's best to veri= fy a multitude of sources while also varying your own perspective as much as= possible over space (i.e. network), time, chosen hardware, chosen software,= etc.=