[conspire] https TLS(/"SSL") certs (was: Re: Risks ...)

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [conspire] Risks ...
> Date: Thu, 28 Mar 2019 01:06:42 -0700

> Quoting Texx (texxgadget at gmail.com):
>
>> Michael's post reminds me of a pet peeve (Think his name is Irving).
>> People go to the trouble of setting up certs, but cant be bothered to
>> renew them when they expire.  To me, this makes certs TOTALLY F*****G
>> USELESS.
>
> Here's a question you may not have asked yourself:  What is your basis
> for relying on an Web site cert that _hasn't_ expired?
>
> Most people's operational answer involves seeing a lock icon and
> inferring a CA attestation.  Let's take that as true.  Doing so moves
> the question one step back:  Why do you have confidence in a cert that
> merely has a CA attestation?
>
> This is where most people answering these questions start wondering
> about the garden path they're on, and having doubts.  THe bolder among
> them might say, somewhat tentatively 'I have reasonable faith in the
> CA my online bank does business with.'  And maybe that faith is
> justified -- but the problem is that the lock icon doesn't say who
> attests to this instance of the cert for the site claiming to be your
> online bank.  All you know from the lock icon is that there's current
> attestation by a CA whose public signing key's in your Web browser's
> cert bundle.  That's something like 300 CAs distributed all around the
> world, and some of those CAs have proven over the past 20 years to be
> extremely skeevy and/or inept and/or corrupt and/or subject to control
> of spook agencies (possibly among others) for nefarious purposes.
>
> So, if relying on Web broswers' normal visual indications of 'valid'
> https, you really have absolutely no idea which of those 300+ CAs
> are attesting to this cert.  It might be a completely different cert
> from the one you loaded half an hour ago when you last visited your
> online banking, and it might be for an imposter Web site being operated
> in Cyprus by a gang of criminals who've sought out and paid the least
> honest and reputable of the world's 300+ CAs to forge your bank's SSL
> cert.  And maybe you're sitting in a Starbuck's whose cheap border
> router has been zombified by those crooks to send requests for your
> bank's Web site to the fraud site in Cyprus.  You'd literally not be
> able to tell, because the conventional Web browser usage model puts
> full trust into all CAs' signing keys and tells the user nothing about
> suspicious changse.
>
> (Michael has already hear past iterations of this speech, along with
> specific examples of why trusting all the CAs of the world is a dreadful
> idea, but you hadn't.)

Yes, as Rick is often quick to point out :-)
the https Certificate Authority (CA) situation is (paraphrasing?)
quite a mess.

So ... what does https and a (non-expired properly installed and
configured) CA cert get one?  Well, a little lock icon thingy or the
like, and ... end-to-"end" encryption - at least between client and
(some) server.  Uhm, and to what "end"?  Well, the whole CA cert "mess"
sure, it gets you encryption, but ... guaranteed that you're getting to
the correct, intended/presumed penultimate "end" ... rather than being
Man-In-The-Middle (MITM) compromised/attacked?  Well, not so much.
Bad CA, or compromised/leaked private key (servers, and those who manage
them aren't unknown to do stupid things, have security incidents - sometimes
that they don't know about or only learn of much later, etc.).
So, sure, it's (well, I'd and many, but far from all) would argue that it's
certainly at least better than nothing.  Though, too, many would well
counter-argue that it's worse, as folks presume it's much more secure than
it is - most notably presuming that little lock icon or the like means all
is fine and hunky dory and that the connection is secure and they're
actually only communicating with the end entity that they think/believe
they are - and that nobody's mucking with things between, doing MITM,
or impersonating the intended end server target, etc.

And Rick also makes good point that the browsers (most/all?) don't - right
along with the lock icon or such, let you know which CA issued the
cert ... well, they generally make that info. available ... but that's
generally at least one or more clicks away - not displayed right along
with the lock icon or such.  And most users almost never look at those
details - at least if they see that lock icon and there isn't otherwise
some significant/major clue(s) that they ought be suspicious of
something ... anything ... or of the cert or its issuer.

"Of course", to also make matters worse, there are some (e.g. certain
companies) that, in the name of "security", do a built-in MITM attack
on most or all desktop communications.  Why in the hell would they do
that?  Oh, they're afraid some bad or unauthorized data might go in
or out ... so ... they decrypt and snoop/filter on all of it - maybe
even modify it.  Personally I think that's a *really bad idea* - for
so many many many reasons ... but that's another topic.

And, if this CA thing is a bloody mess or whatever, why use it, or what
can be done or what has been done to improve it?  Well, I'm not going to
lay out all the various details, but yes, some things have been done
to improve it / the process ... but yes, it's still far from perfect.

However, there are additional measures that those operating the
services - notably domains and DNS can take.  So, ... there's
CAA Resource Records (RR)s, e.g.:
$ dig +noall +answer +nottl balug.org. CAA
balug.org.              IN      CAA     128 issuewild "letsencrypt.org"
balug.org.              IN      CAA     0 iodef "mailto:hostmaster at balug.org"
balug.org.              IN      CAA     128 issue "letsencrypt.org"
$
And, what's that?  Those are DNS records that say what CAs may grant
certs for the domain.  The CAs "must" (are supposed to) check for that
DNS data before issuing certs.  But more importantly, browsers/clients
can also check that data.  Now, what browsers actually do such check,
and if they give any indication they've checked, and if there's
CAA record(s) and that matches the cert ... yeah, that's another matter.
But at least if the browsers do check, and CAA conflicts with
issuance of cert, browsers should at least clearly warn (if not outright
reject) the CA cert that doesn't match the CAA data.  So that can
help make the https cert stuff somewhat more, uh, "secure" ... at least
with such records, the domain says, no, you can't use any old cert from
> ~=300 CAs for this domain, you should only see/trust, and we only
authorized this(/these) specific CAs to issue certs for our domain.
Oh, and that CAA data - its more for reading/interpreting by CAs and
browsers ... not exactly super-friendly for the average browser-wielding
user to directly use ... but one can certainly also look up the
relevant technical bits and what it all means, if one wants (it's not
all that horribly difficult to understand/interpret - once one is
familiar with it - or has the relevant references at hand).
Anyway, in example above, that says (in short) for balug.org,
only CA letsencrypt.org is permitted to issue certs for that domain,
and browsers should reject any certs for that domain not issued by
CA letsencrypt.org.  (But what of transition to another CA, or multiple CAs,
you may ask?  Easy - more CAA records - one can permit more than one CA.)

Okay, so there's CAA that can be used by browsers (if they bother).  What
else?  :-)  Well, there is, of course, also
DNSSEC.  :-)  Horribly underutilized 8-O - at least in the US, but some
places around the world have much higher deployment rates.  And, what does
DNSSEC do?  Allows for cryptographic verification of DNS data.  Without
such on that, its a significant weakness - DNS can be spoofed,
and DNS spoofing plus bad CA actors and/or other https cert
problems (like a stolen private key) makes for a very bad combination
(notably very effective spoofing / MITM).  DNSSEC alone helps that
some fair bit (but still won't stop all MITM and the like), but the
combination of DNSSEC and CAA makes a relatively strong combination.
So, yes, some domains/sites use both (e.g. [www.]balug.org) ... but
many don't.

Anyway, CA cert stuff - certainly a messy imperfect, uh, "solution".
But that doesn't mean it can't be improved upon - directly (e.g. toss
out the bad CA actors - and that's certainly sometimes happened)
and/or indirectly (e.g. DNSSEC and/or CAA - adding more security layers).