On 2022-01-04 at 14:37:18 UTC-0500 (Tue, 4 Jan 2022 11:37:18 -0800)
Michael <keybou...@gmail.com>
is rumored to have said:
On 2022-01-03, at 4:12 PM, Richard L. Hamilton <rlha...@smart.net>
wrote:
The only problem with that or anything similar, is that unless you go
to quite a lot of work to just download rather than install the PEM
file, and convert it into something human readable WITHOUT installing
it, and investigate every certificate in there, you're trusting that
the site you got it from is not only legit, but is secure and hasn't
been hacked to alter the file to provide some very bogus certificates
that could work together with some sort DNS spoofing to get you to
feed sensitive information (ie bank passwords, etc) via an untrusted
site that would capture it.
Makes sense. Now, how do you go about turning a certificate into
something human readable? Serious question, I have *never* seen this
discussed anywhere.
Get the certificate in PEM format, then:
openssl x509 -text < cert.pem
See the man page ('man x509') for all the very gory details.
Everyone just says "As long as the roots are good you can trust the
chain", and that's never made sense to me. The whole "trust what
strangers say" system seems more like "Find a way for companies to
make money" than any good security system.
Well, yes: that's what the public CA system is. It is grounded in the
OSI protocol stack, which is big on hierarchical authority, and no one
has figured out a better model that scales and allows strangers to
establish authenticated private data transport. Ultimately it requires
shared trust anchors of some sort, and the model we've stumbled into has
the advantage of not being subject to a single authority and encouraging
the various CAs and bundlers of trust to keep watch on each other.
A mechanism for eliminating the CA-based hierarchical trust layer
already exists in the DANE (DNS-based Authentication of Named Entities)
standard that is in broad use for validating email trasnsport. It
replaces the CA model by binding the trust chain to DNS, making
certificate trust ultimately dependent on DNSSEC and subject to all of
its risks.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
