From owner-freebsd-gecko@FreeBSD.ORG Fri Jul 4 15:43:57 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 34776684 for ; Fri, 4 Jul 2014 15:43:57 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 DF682266D for ; Fri, 4 Jul 2014 15:43:56 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id i50so1588632qgf.26 for ; Fri, 04 Jul 2014 08:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pTo/0Lk6YNKZmN9T7ZD37F2gtWtffdn5BR1H0RQF3Bg=; b=TM8v+L8LPODSe51n7H/gwp6hza9kYvk1Q/gP3W88FDtaMxasKPEdmgpsyLcMch8zRw 7KvtKSeX9hFD2cEZKm1HYTNHg7nGzGYT+4kEPOdQHBqFMmB4I9h+jtDNXFRJkn03TTFy ejryY/Tb0VtVSgcJ0GJjABpYSxiTp5hLYAtM0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pTo/0Lk6YNKZmN9T7ZD37F2gtWtffdn5BR1H0RQF3Bg=; b=PSRnjzqILENyMHfWk0BmP5vWD51i9bUSwxIJwmzT+YHa/HWmLk7WwrQma6yfiYMDBl jn+9YQHI1vDWDjuQth3IoR9vAADd0gY0ApK/WyQCeAS9+wPPFS6/CHTQ9x+mJ9DDUcgr l5EMjpaZXgErsqCDvP6my3eNH+mo+RfA0KkuBhg3inBrwM/mLCzOCsKk77yOUGBpH5Uu eo6JWJuIRqhx7r8Inhm8c1/uvNH9kM72BS3ZbpJEAMgSd4FUsyfieD+wrJhwpZCjk73Z iUkESQV1nCOLkz96avLXEn4cKHLhG/diKLlvfnWI1qnuqFLjYkoGlQSFE+FW3T4RBQGM kI0w== X-Gm-Message-State: ALoCoQkuaHVaHd+cu3dj73axEjgmufflNOiWIbD5uAWY6LyW29zODqu7hS7z0ZjnLLls24l8hkQG X-Received: by 10.140.81.209 with SMTP id f75mr12676501qgd.60.1404488635809; Fri, 04 Jul 2014 08:43:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.88.132 with HTTP; Fri, 4 Jul 2014 08:43:25 -0700 (PDT) In-Reply-To: References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> <53B57FC9.4080302@FreeBSD.org> From: Eitan Adler Date: Fri, 4 Jul 2014 08:43:25 -0700 Message-ID: Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Cc: Xin LI , gecko@freebsd.org, Bryan Drewery , "freebsd-security@freebsd.org security" , Jung-uk Kim , FreeBSD Ports Management Team , re , Jonathan Anderson 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 15:43:57 -0000 On 4 July 2014 02:11, Ben Laurie wrote: > 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. Lets stop conflating "default" with "policy decision". -- Eitan Adler