From owner-freebsd-gecko@FreeBSD.ORG Fri Jul 4 09:11:11 2014 Return-Path: Delivered-To: gecko@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CC8B303; Fri, 4 Jul 2014 09:11:11 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B88F21EA; Fri, 4 Jul 2014 09:11:10 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id z60so1248433qgd.10 for ; Fri, 04 Jul 2014 02:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=E4br/D52iCuYMDohgp4u6JGr2gha5COH+dEQXhWRtts=; b=EC64YpF+aq4aOPH+msWYIlnaMwmGTxezkBJDvyu1am7TMAy5F4PqS2L8Mqu1qJU0nH Y/WhhHQTF0Jaw4Gm23txS6dhLRMv/8sw3SPjufn/FdrjsBEVV6zauxrU4Oa5oN+yaxxW Vbd0EKaAf/ZCG2YvfxIvoKiIeVidqLEb0uGCtC1HLujwWqWHK5I5zVtJTJsioH75Y9WV uN6oCyipvJzNx1W4KC1PWJ+KDMfYXCG1Ukl1tumoxgAnEzo3VbukvMeoCJ3M6xNw1tAY Nf0sN5BuNNjfRD6ztcY48blW//uWJReip7DJKbZfphPmFByxrS6+TPOvoZK6GyqxPeuo sQ4A== MIME-Version: 1.0 X-Received: by 10.140.43.118 with SMTP id d109mr15621218qga.10.1404465069706; Fri, 04 Jul 2014 02:11:09 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.222.168 with HTTP; Fri, 4 Jul 2014 02:11:09 -0700 (PDT) In-Reply-To: <53B57FC9.4080302@FreeBSD.org> References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> <53B57FC9.4080302@FreeBSD.org> Date: Fri, 4 Jul 2014 10:11:09 +0100 X-Google-Sender-Auth: A4KjhhtT0fbirSXNunH7pXzekSs Message-ID: Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? From: Ben Laurie To: Jonathan Anderson Content-Type: text/plain; charset=UTF-8 Cc: Xin LI , gecko@freebsd.org, Bryan Drewery , "freebsd-security@freebsd.org security" , FreeBSD Ports Management Team , re , Jung-uk Kim X-BeenThere: freebsd-gecko@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Gecko Rendering Engine issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 09:11:11 -0000 On 3 July 2014 17:07, Jonathan Anderson wrote: > Eitan Adler wrote: >> >> Perhaps we should remove HTTPS support from libfetch and require the >> user to install wget or curl if they want to use SSL? Having a >> *default* certificate bundle (that could be removed / edited, of >> course) is not necessarily even making a trust claim about a >> particular cert. [0] IMHO the position where the majority of SSL on >> the internet is broken by default is not tenable. >> >> We support HTTP. We don't support HTTPS. The browsers spend a lot of >> time on this problem. We don't. I am not asserting that the Mozilla >> set is perfect. I am asserting that we should have *functional* SSL >> in the base system, and that using the Mozilla set is a good way to >> obtain that with a good enough policy. > > > I think it's useful to provide the *mechanism* (libfetch does validation of > whatever certs you put in /usr/local/etc/ssl), I'm just saying that we > should be very conservative about *policy*: we can vouch for exactly one > certificate, and that's the one we control. Vendors who base their products > on FreeBSD might choose to pre-populate /etc/ssl with ca-freebsd.pem and > ca-vendor.pem, while people who install FreeBSD boxes can choose to install > a CA bundle package to /usr/local/etc/ssl. > > I do see a couple of potential solutions to the "I can't fetch anything on > my clean install" problem. First, we can make sure that CA bundles are in > the set of packages we put on the install media, so the person installing > the OS can choose to adopt the "accept whatever CAs Mozilla likes" policy > (or the "accept CAs that Dr Paranoid likes" policy). Second, we could let > interactive 'fetch' warn users about unrecognized CAs (different from > validation failures) and prompt as to whether or not they want to continue > with the fetching. That behaviour would be no worse than manually specifying > --no-verify-peer, which is the logical next step when you see a missing CA > error today. +1. I agree that not making policy decisions on behalf of the user is the right thing to do, but likewise, leaving them entirely to their own devices will just lead to further fail, so a port or ports that will allow users to adopt someone else's policy seems like a necessary part of the equation.