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
