grarpamp wrote this message on Wed, Feb 24, 2021 at 23:38
-0500:> FYI...
>
> Third party CA's are an untrusted automagical nightmare of global and
> local MITM risk...
Do you delete all the CA's from your browsers then?
Having tried to verify the certificate for a bank when verisign f'd
up their cert really doesn't work, trust me I've tried it, the
support has zero clue what you're talking about, and they have no
process to handle such a question...
> - CA's issuer gone wrong... Govt, Corp, Bribe, Rogue, Court, War,
> Force Majeure, Crime, Hack, Spies, Lulz, etc.
> - CA's store bundler gone wrong... Mozilla, Microsoft, Apple, BSD, etc
> in same ways above.
> - Undetected stolen unrevoked unchecked CA's, intermediates, server
keys, etc.
> - Total/targeted IP/DNS traffic user interception by agents, vpn's,
> proxies, tor, mitmproxy, sslstrip, etc.
> - Base asserting trust over all that, when reality none is due.
It's even worse if you disable ALL cert checking, and force people to use
--no-verify-peer, as then anyone can MitM the connection instead of a
reduced set of people..
Considering that pkg used to, by default, d/l packages in clear text,
it was very easy to know if a FreeBSD box has CA installed or not,
making someone who wants to MitM FreeBSD hosts have an idea of what
machines they could likely MitM w/o getting caught making this even
MORE dangerous...
> There should be no non-FreeBSD.Org/Foundation CA's shipped in base.
Except that FreeBSD.org doesn't have it's own CA. This means that
either there isn't ANY certificate, and people couldn't securely d/l
from
www.freebsd.org out of the box, OR, we use let's encrypt cert, which means
that 240 million+ websites would be supported out of the box... And
as you say below, you really have a axe to grind w/ Let's Encrypt, despite
them being more secure because of the short expiration of certs...
Because CRL's are pretty much universally ignored... so, even if a CA
(or a user) revokes a certificate, it's still likely mostly valid...
> Its shipped pubkey fingerprint sets can bootstrap TLS infra pubkeys/prints
> off bsd keyserver, to then pubkey pin TLS fetch(1) / pkg(8) / git(1) to
reach
> pkg ca_root_cert, git src ports repos, update, iso, etc.
> See curl(1) --pinned-pubkey, GPG, etc.
pkg install ca_root_cert was already able to be securely installed
before this using a similar method..
> Users should delete all those ~139 garbage CA's,
> only add in the ones they find they need during use,
> easily scripted and tooled, start with say the...
> - LetsEncrypt chain
That's what the certctl tool is for, to let users easily able to do this..
certctl list | tail -n +2 | awk '{ print $1 }' | xargs -n 1 certctl
blacklist
> And force TLS pubkey fingerprint pin check on critical services.
>
> Search web for howtos.
>
> At minimum require user / install to ack before use...
> mv /etc/ssl/certs.shipped_disabled /etc/ssl/certs
Last I checked no browser requires users to ack to install those CA's
have you attempted to pressure them to?
I'm personally much happier to have them installed by default then before
where people were using --no-verify-peer to d/l stuff.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."