From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-user+bounces-196139-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6BFF11382C5 for <garchives@archives.gentoo.org>; Wed, 2 Jun 2021 01:51:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 63360E0863; Wed, 2 Jun 2021 01:50:59 +0000 (UTC) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E3200E0849 for <gentoo-user@lists.gentoo.org>; Wed, 2 Jun 2021 01:50:58 +0000 (UTC) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id 1521ouDO014922 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <gentoo-user@lists.gentoo.org>; Tue, 1 Jun 2021 20:50:57 -0500 Subject: Re: [gentoo-user] app-misc/ca-certificates To: gentoo-user@lists.gentoo.org References: <20210529030839.123d8526@melika.host77.tld> <YLHesQZxAxw+TftG@waltdnes.org> <5480288.DvuYhMxLoT@iris> <61db8745-dbb4-9c7e-80a9-6725905178c4@iinet.net.au> <1cc069e9-b708-c994-ca93-dc0a2d77f8f9@spamtrap.tnetconsulting.net> <e3af2cc757588b4599cc4e06308947b003cadfab.camel@gentoo.org> From: Grant Taylor <gtaylor@gentoo.tnetconsulting.net> Organization: TNet Consulting Message-ID: <5f29a4f8-a1a5-9f4a-1fe2-f06172da8e6b@spamtrap.tnetconsulting.net> Date: Tue, 1 Jun 2021 19:51:06 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 Precedence: bulk List-Post: <mailto:gentoo-user@lists.gentoo.org> List-Help: <mailto:gentoo-user+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-user.gentoo.org> X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: <e3af2cc757588b4599cc4e06308947b003cadfab.camel@gentoo.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 0cc26e97-b122-4011-bd47-8b7748e1d0fd X-Archives-Hash: 46368cd204d1f1b1269cbc4108b8b833 On 6/1/21 3:38 PM, Michael Orlitzky wrote: > *Any* CA can just generate a new key and sign the corresponding > certificate. This is where what can /technically/ be done diverges from what is /allowed/ to be done. CAs adhering to the CA/B Forum's requirements on CAA records mean that they aren't allowed to issue a certificate for a domain that doesn't list them in the CAA record. If a CA violates the CAA record requirement, then the CA has bigger issues and will be subject to distrusting in mass. Certificate Transparency logs make it a lot easier to identify if such shenanigans are done. -- I think that the CA/B Forum is also requiring C.T. Logs. Also, CAs /should/ *NOT* be generating keys. The keys should be generated by the malicious party trying to pull the shenanigans that you're talking about. > All browsers will treat their fake certificate corresponding to the > fake key on their fake web server as completely legitimate. The "real" > original key that you generated has no special technical properties > that distinguish it. Not /all/ browsers. I know people that have run browser extensions to validate the TLS certificate that they receive against records published via DANE in DNS, which is protected by DNSSEC. So it's effectively impossible for a rogue CA and malicious actor to violate that chain of trust in a way that can't be detected and acted on. -- Grant. . . . unix || die