From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 59086138239 for ; Tue, 1 Jun 2021 11:59:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D71B9E0863; Tue, 1 Jun 2021 11:59:27 +0000 (UTC) Received: from mail-oo1-xc34.google.com (mail-oo1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 F05BAE0855 for ; Tue, 1 Jun 2021 11:59:26 +0000 (UTC) Received: by mail-oo1-xc34.google.com with SMTP id 67-20020a4a01460000b0290245b81f6261so865536oor.6 for ; Tue, 01 Jun 2021 04:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AhKlJATWixh/0L3MRHnsQXMAX0GW9ldJNkBsFkLdmt8=; b=CuBm+JNSyjlRAjbgRn7rJEkYZ5+/QhjvlX3oV2LK6jHZIAEwEoVuUuoTjAjkRkUmM6 eaeU6ZkRYPhE8fe98/qO2GdkUMkead0/Gw2dDh61A7kX+idtj8R24QG03wEkvAN9H5a6 tRRbTXBDng7n0nIZ/3F3Nx34bwRxwmBwk97mkW6PPQmCcOuYhPwoCTsyhY12BpKdC0lk eoK6sqV4LYkmfQscbCq8joCDGocUNRnbR1asWkquhSweeo7GNq41oflDZvKzQvFneM3S DyMSNkyyPuhP9Eusk9yjK3E7yueKdyq8TbQ1suwutixiszylC12CKd+lAVSvNWLEOHB+ NAnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AhKlJATWixh/0L3MRHnsQXMAX0GW9ldJNkBsFkLdmt8=; b=Di/fubUGIaJA2dY4FOBtczASo8b8aYiOXlh2g1LN2kbgZq0+5XH71MnxM8qdreEbdd +sdWLXw1zHXvHOtJygXtFR8M2lbf+J9b7v/W2URmX8jyqM3x591UiAXc0NZ65zceJs+g f+HvbWAZs52XjFvzM3np0XUbFu2U+VN1HjiQOkYBxS+lmAF7H3NAfTDqu1sVngOeUS4c qz3c0LSZQqWkbT4+e+T74gsRfvy0pPsKuUtMR53NDGKtHc9HvXt7RezUvhxBHppdcuH+ z9fLVGeqMSHOjLI2X1GwaOrBmC3Iz8vBv4IP6RKxtrlzPu7odGbgSSfRBp8MxcKKf+U7 gtmg== X-Gm-Message-State: AOAM5335Suc5SMonW/GJuDm6GY/WfJRfiUSrv0MR0wI1RT7wnWrznH3y R+2axlnGZaO9gW1N610lZJbiaiUKrP66rOOAguDTgDv83kU= X-Google-Smtp-Source: ABdhPJxsySR2/5k2+hBSfvpxy3Qxuku3Qftef6gtgX6XFRUXj9KoDZ3FKEUu31WvZ1YgzpR3FvfIKDLZp5jS6ilFI9g= X-Received: by 2002:a4a:6765:: with SMTP id j37mr14958156oof.57.1622548766091; Tue, 01 Jun 2021 04:59:26 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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 References: <20210529030839.123d8526@melika.host77.tld> <5480288.DvuYhMxLoT@iris> <61db8745-dbb4-9c7e-80a9-6725905178c4@iinet.net.au> In-Reply-To: <61db8745-dbb4-9c7e-80a9-6725905178c4@iinet.net.au> From: Adam Carter Date: Tue, 1 Jun 2021 21:59:15 +1000 Message-ID: Subject: Re: [gentoo-user] app-misc/ca-certificates To: Gentoo User Content-Type: multipart/alternative; boundary="000000000000d56cee05c3b312e8" X-Archives-Salt: 3093cc2b-daeb-4f72-b178-35bd21c6d57f X-Archives-Hash: 3f10bc6eefebf194dd86e1fc341abe4a --000000000000d56cee05c3b312e8 Content-Type: text/plain; charset="UTF-8" > > And another "wondering" - all the warnings about trusting self signed > certs seem a bit self serving. Yes, they are trying to certify who you > are, but at the expense of probably allowing access to your > communications by "authorised parties" (such as commercial entities > purchasing access for MITM access - e.g. certain router/firewall > companies doing deep inspection of SSL via resigning or owning both end > points). CAs who issue such dodgy certs tend to get booted from certificate stores, since they cannot be trusted. https://wiki.mozilla.org/CA:Symantec_Issues#Issue_D:_Test_Certificate_Misissuance_.28April_2009_-_September_2015.29 https://en.wikipedia.org/wiki/Certificate_Transparency helps keep CAs honest. The way i like to frame it is "any certificate should only be trusted as much as the *least* trustworthy CA in your certificate store" AFAIK in an enterprise MITM works by having a local CA added to the cert stores of the workstation fleet, and having that CA auto generate the certs for MITM. That didn't work with certificate pinning, but pinning has been deprecated. > If its only your own communications and not with a third, > commercial party self signed seems a lot more secure. > Yes, I imagine there are some circumstances where it would make sense to remove all the certs from your certificate store and then just add your local CA's cert. In this case, the least trustworthy CA in the store is your own :) --000000000000d56cee05c3b312e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And another "wondering" - all the warnings about trusting self si= gned
certs seem a bit self serving. Yes, they are trying to certify who you
are, but at the expense of probably allowing access to your
communications by "authorised parties" (such as commercial entiti= es
purchasing access for MITM access - e.g. certain router/firewall
companies doing deep inspection of SSL via resigning or owning both end
points).

CAs who issue such dodgy certs te= nd to get booted from certificate stores, since they cannot be trusted.

<= br>
The way i like to frame it is "any certificate should on= ly be trusted as much as the least trustworthy CA in your certificat= e store"

AFAIK in an enterprise MITM works by= having a local CA added to the cert stores of the workstation fleet, and h= aving that CA auto generate the certs for MITM. That didn't work with c= ertificate pinning, but pinning has been deprecated.
=C2=A0
If its only your own = communications and not with a third,
commercial party self signed seems a lot more secure.

Yes, I imagine there are some circumstance= s where it would make sense to remove all the certs from your certificate s= tore and then just add your local CA's cert. In this case, the least tr= ustworthy CA in the store is your own :)
--000000000000d56cee05c3b312e8--