From nobody Sun Dec 4 06:16:45 2022 X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NPxKT10Srz4jTJt for ; Sun, 4 Dec 2022 06:17:01 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mr85p00im-ztdg06021201.me.com (mr85p00im-ztdg06021201.me.com [17.58.23.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NPxKS4jFZz4Wmt for ; Sun, 4 Dec 2022 06:17:00 +0000 (UTC) (envelope-from gordon@tetlows.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tetlows.org; s=sig1; t=1670134619; bh=wVaLjZc+H7aC5nF+TF4Y+bffPGR0jwjMsHIppMvSeho=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=qqIicwSEkmH2HqLBB69h+CcOgIZUJorpc0DsawV3ezBdaMtAyGw4w/azWzztNBJUS 0ryvA1UYRgdPPJtmEwBik1/hciCGNOCcwkOS+kmql9hU8ZYm52GTzTQi4K1HtXtNZ4 fxTmwrg4bhWdjzgtcIi40NsDHrmPIRfnbaaoW0Lhu5D+xnMuLvwSUpGxp6CDkpj6NZ PmzjvXR2NcjdD3A4GCd2zglolyhv1lhI3mArJBe1f9FtuO9xsrL/NWxMX2uf7Velsc acSg9bdhyAg+e6fgh+dSEqmLpHdZ9+UMktAawPE5ip/iqPWMT7lubBQ18Rwj6DizpP Wp8ETyJLRnpRQ== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-ztdg06021201.me.com (Postfix) with ESMTPSA id 7B33D320795; Sun, 4 Dec 2022 06:16:58 +0000 (UTC) From: Gordon Tetlow Message-Id: <3FD4E3F3-EAAB-41E9-9381-D98971A9B928@tetlows.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F" List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: CA's TLS Certificate Bundle in base = BAD Date: Sat, 3 Dec 2022 22:16:45 -0800 In-Reply-To: Cc: freebsd-security@freebsd.org, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-pkg@freebsd.org To: grarpamp References: X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Proofpoint-GUID: JdfdEwSXJIZROAN6ZP9MzHqHobNhHuNt X-Proofpoint-ORIG-GUID: JdfdEwSXJIZROAN6ZP9MzHqHobNhHuNt X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.816,17.11.62.513.0000000_definitions?= =?UTF-8?Q?=3D2022-01-18=5F01:2020-02-14=5F02,2022-01-18=5F01,2021-12-02?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 adultscore=0 clxscore=1030 phishscore=0 malwarescore=0 spamscore=0 mlxlogscore=385 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2212040058 X-Rspamd-Queue-Id: 4NPxKS4jFZz4Wmt X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 3, 2022, at 5:26 PM, grarpamp wrote: >=20 > Again, FreeBSD should not be including the bundle in base, if users > choose to, they can get it from ports or packages or wherever else. > Including such bundles exposes users worldwide to massive risks. > You need to do more gpg attestation, pubkey pinning [1], tofu, and > cert management starting from empty file... and quit trusting bundles = of > hundreds of random CA's, all of which are entities who have zero duty > or care to the user, and often exist/corrupt/break to present evil [2] = ... >=20 > [1] > = https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d > = https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDP= UBLICKEY.3 >=20 > FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple = option, > thus they're incapable of securely fetching packages, iso's, etc from > servers in re [2]. Nor does FreeBSD even post sigs over its servers = pubkeys > for users to get, verify, and pin out of band. Even pubkeys were = swapped out > on FreeBSD servers without announcing for users if any exploit or loss = occurred > there or for some other reason. That's all bad news :( But can be = fixed :) Key pinning is a bad idea that 100% will cause outages. As a thought experiment, let's suppose I (as the Security Officer) use = the system you propose and require users to pin specific keys on our = publicly available servers. Now let's further suppose that the project = is compromised such that we believe those certificates might be in the = hands of the attacker, but we aren't sure. I'm now stuck between a rock = and hard place. Should I rotate the pinned certificate? In your proposed = system, rotating that pinned certificate will cause massive downstream = failures for all users. Since we aren't sure, maybe I'll leave the = existing certificate in place, because I don't want to cause those = outages since I'm not sure it's a problem. In the publicly trusted CA system, I can easily rotate the certificate = even if I don't believe it was compromised. It incentivizes better = behavior. Also, please don't lecture me on the problems with the = publicly trusted CA system: I'm very familiar with them. That said, it's = the system we have and I have no interest in trying to tilt at that = particular windmill. In any event, nothing is preventing you from doing this on your own as = the system ships with the tools to do so. Recognize the project has a = need for cryptographic agility and ability to change certificates = whenever we need to. Running our own root CA infrastructure necessary to = provide a similar level of assurance to a professionally run CA is = non-trivial and I don't believe we as a project are in a position (or = interested) in taking on such a burden. Gordon= --Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Dec 3, = 2022, at 5:26 PM, grarpamp <grarpamp@gmail.com> = wrote:

Again, = FreeBSD should not be including the bundle in base, if users
choose to, they can get it from ports or = packages or wherever else.
Including such bundles exposes users worldwide to massive = risks.
You need to do more gpg = attestation, pubkey pinning [1], tofu, and
cert = management starting from empty file... and quit trusting bundles = of
hundreds of random CA's, = all of which are entities who have zero duty
or care to the user, and often = exist/corrupt/break to present evil [2] ...

[1]
https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpub= key.d
https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_P= INNEDPUBLICKEY.3

FreeBSD pkg(8) (aka, = and: fetch(3)) don't even support this simple option,
thus they're incapable of securely fetching = packages, iso's, etc from
servers = in re [2]. Nor does FreeBSD even post sigs over its servers = pubkeys
for users to get, = verify, and pin out of band. Even pubkeys were swapped out
on FreeBSD servers without announcing for = users if any exploit or loss occurred
there = or for some other reason. That's all bad news :( But can be fixed = :)

Key pinning is a bad idea = that 100% will cause outages.

As a thought = experiment, let's suppose I (as the Security Officer) use the system you = propose and require users to pin specific keys on our publicly available = servers. Now let's further suppose that the project is compromised such = that we believe those certificates might be in the hands of the = attacker, but we aren't sure. I'm now stuck between a rock and hard = place. Should I rotate the pinned certificate? In your proposed system, = rotating that pinned certificate will cause massive downstream failures = for all users. Since we aren't sure, maybe I'll leave the existing = certificate in place, because I don't want to cause those outages since = I'm not sure it's a problem.

In the publicly = trusted CA system, I can easily rotate the certificate even if I don't = believe it was compromised. It incentivizes better behavior. Also, = please don't lecture me on the problems with the publicly trusted CA = system: I'm very familiar with them. That said, it's the system we have = and I have no interest in trying to tilt at that particular = windmill.

In any event, nothing is preventing = you from doing this on your own as the system ships with the tools to do = so. Recognize the project has a need for cryptographic agility and = ability to change certificates whenever we need to. Running our own root = CA infrastructure necessary to provide a similar level of assurance to a = professionally run CA is non-trivial and I don't believe we as a project = are in a position (or interested) in taking on such a = burden.

Gordon
= --Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F--