Re: [gentoo-user] app-misc/ca-certificates

[Grant Taylor]

On 5/31/21 11:15 PM, William Kenworthy wrote:
> And another "wondering" - all the warnings about trusting self signed
> certs seem a bit self serving.

No, it's not self serving.

Considerably more people than public certificate authorities bemoan self 
signed certificates.

Consider this:

1)  Your web site uses a self signed certificate and you have trained 
users to blindly accept and trust the certificate presented to them.
2)  Someone decides to intercept the traffic and presents a different 
self signed certificate to the end users while proxying the traffic on 
to you.
3)  Your end users have no viable way to differentiate between your self 
signed certificate and the intercepting self signed certificate.

Without someone - which you trust - vouching for the identity of the 
party that you're connecting to, you have no way to know that you are 
actually connecting to the partying that you are intending to connect to.

> Yes, they are trying to certify who you are, but at the expense of
> probably allowing access to your communications by "authorised parties"

Nope.  Not at all.  (Presuming that it's done properly.  More below.)

The /only/ thing that the certificate does / provides is someone - whom 
end users supposedly trust - vouching that you are who you say they are. 
  The CA has nothing in the actual communications path.  Thus they can't 
see the traffic if they want to.

The proper way configure certificates is:

1)  Create a key on the local server.
2)  Create a Certificate Signing Request (a.k.a. CSR) which references, 
but does not include, the key.
3)  As a CA to sign the CSR.
4)  Use the certificate from the CA.

The important thing is that the key, which is integral to the encryption 
*NEVER* *LEAVES* *YOUR* *CONTROL*!

Thus there is no way that a CA is even capable of getting in the middle 
of the end-to-end communications between you and your client.

There have been some CAs in the past that would try to do everything on 
their server.  But in doing so, they violate the security model.  Don't 
use those CAs.

*YOU* /must/ generate the key /locally/.  Anything else is broken security.

> (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).

This is actually exceedingly difficult to do, at least insofar as 
decryption and re-encrypting the traffic.  Certificate Transparency logs 
help ensure that a CA doesn't ... inadvertantly ... issue a certificate 
that they should not.  Or at least it makes it orders of magnitude 
easier to identify and detect when such ... mistakes happen.

There is also the Certificate Authority Authorization record that you 
can put in DNS that authorizes which CA(s) can issue certificates for a 
domain.  A few years ago we passed the deadline where all CAs had to 
adhere to the CAA record.  As in the Certificate Authority / Browser 
forum / consortium / term??? has non-renewed anybody who wasn't adhering 
to CAA.  This is water so far under the bridge that it's over the 
waterfall, out to ocean, evaporated, and is raining down again.

Also, DNSSEC protects DNS in that it makes it possible to authenticate 
the information you receive.  Thus you can detect when things aren't 
authenticated and you know they should be.

> If its only your own communications and not with a third, commercial
> party self signed seems a lot more secure.

Nope.  3rd parties don't have access to the encrypted communications. 
The only thing they have access to is saying if you are you or not. 
Yes, that's Bob over there in the corner.  But I have no idea what he's 
talking about b/c MATH.

Note the words "signed" and "signing".  A Certificate Authority signs a 
certificate signing request, thus vouching for the identity of the 
entity submitting the CSR.  You obviously can sign your own CSR.  That's 
what a self-signed certificate comes from.  But you have nobody vouching 
for who the far entity is, much less who vouched for them.

Spekaing of who vouched for them, and how do we trust them?  That's 
where the hashes in /etc/ssl (or wherever it is) come into play.  Your 
system has a public key for /trusted/ root CAs.  Thus when your system 
sees a certificate signed by a CA, it computes the hash, looks for the 
public key as the hash file on your local system.  If the file exists 
and all the math passes, then the root certificate is trusted.  If the 
root certificate is trusted, then your system will trust the certificate 
that the CA is vouching for.

This is all ... something ... having to do with who is vouching for whom 
and do you trust the vouching party or not.

But at no time does a CA have access to the encrypted communications. 
As long as things were done properly in that the keys were generated 
locally.



-- 
Grant. . . .
unix || die