Gentoo Archives: gentoo-user

From: Grant Taylor <gtaylor@×××××××××××××××××××××.net>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] app-misc/ca-certificates
Date: Tue, 01 Jun 2021 21:24:58
In Reply to: Re: [gentoo-user] app-misc/ca-certificates by William Kenworthy
1 On 5/31/21 11:15 PM, William Kenworthy wrote:
2 > And another "wondering" - all the warnings about trusting self signed
3 > certs seem a bit self serving.
5 No, it's not self serving.
7 Considerably more people than public certificate authorities bemoan self
8 signed certificates.
10 Consider this:
12 1) Your web site uses a self signed certificate and you have trained
13 users to blindly accept and trust the certificate presented to them.
14 2) Someone decides to intercept the traffic and presents a different
15 self signed certificate to the end users while proxying the traffic on
16 to you.
17 3) Your end users have no viable way to differentiate between your self
18 signed certificate and the intercepting self signed certificate.
20 Without someone - which you trust - vouching for the identity of the
21 party that you're connecting to, you have no way to know that you are
22 actually connecting to the partying that you are intending to connect to.
24 > Yes, they are trying to certify who you are, but at the expense of
25 > probably allowing access to your communications by "authorised parties"
27 Nope. Not at all. (Presuming that it's done properly. More below.)
29 The /only/ thing that the certificate does / provides is someone - whom
30 end users supposedly trust - vouching that you are who you say they are.
31 The CA has nothing in the actual communications path. Thus they can't
32 see the traffic if they want to.
34 The proper way configure certificates is:
36 1) Create a key on the local server.
37 2) Create a Certificate Signing Request (a.k.a. CSR) which references,
38 but does not include, the key.
39 3) As a CA to sign the CSR.
40 4) Use the certificate from the CA.
42 The important thing is that the key, which is integral to the encryption
45 Thus there is no way that a CA is even capable of getting in the middle
46 of the end-to-end communications between you and your client.
48 There have been some CAs in the past that would try to do everything on
49 their server. But in doing so, they violate the security model. Don't
50 use those CAs.
52 *YOU* /must/ generate the key /locally/. Anything else is broken security.
54 > (such as commercial entities purchasing access for MITM access -
55 > e.g. certain router/firewall companies doing deep inspection of
56 > SSL via resigning or owning both end points).
58 This is actually exceedingly difficult to do, at least insofar as
59 decryption and re-encrypting the traffic. Certificate Transparency logs
60 help ensure that a CA doesn't ... inadvertantly ... issue a certificate
61 that they should not. Or at least it makes it orders of magnitude
62 easier to identify and detect when such ... mistakes happen.
64 There is also the Certificate Authority Authorization record that you
65 can put in DNS that authorizes which CA(s) can issue certificates for a
66 domain. A few years ago we passed the deadline where all CAs had to
67 adhere to the CAA record. As in the Certificate Authority / Browser
68 forum / consortium / term??? has non-renewed anybody who wasn't adhering
69 to CAA. This is water so far under the bridge that it's over the
70 waterfall, out to ocean, evaporated, and is raining down again.
72 Also, DNSSEC protects DNS in that it makes it possible to authenticate
73 the information you receive. Thus you can detect when things aren't
74 authenticated and you know they should be.
76 > If its only your own communications and not with a third, commercial
77 > party self signed seems a lot more secure.
79 Nope. 3rd parties don't have access to the encrypted communications.
80 The only thing they have access to is saying if you are you or not.
81 Yes, that's Bob over there in the corner. But I have no idea what he's
82 talking about b/c MATH.
84 Note the words "signed" and "signing". A Certificate Authority signs a
85 certificate signing request, thus vouching for the identity of the
86 entity submitting the CSR. You obviously can sign your own CSR. That's
87 what a self-signed certificate comes from. But you have nobody vouching
88 for who the far entity is, much less who vouched for them.
90 Spekaing of who vouched for them, and how do we trust them? That's
91 where the hashes in /etc/ssl (or wherever it is) come into play. Your
92 system has a public key for /trusted/ root CAs. Thus when your system
93 sees a certificate signed by a CA, it computes the hash, looks for the
94 public key as the hash file on your local system. If the file exists
95 and all the math passes, then the root certificate is trusted. If the
96 root certificate is trusted, then your system will trust the certificate
97 that the CA is vouching for.
99 This is all ... something ... having to do with who is vouching for whom
100 and do you trust the vouching party or not.
102 But at no time does a CA have access to the encrypted communications.
103 As long as things were done properly in that the keys were generated
104 locally.
108 --
109 Grant. . . .
110 unix || die


Subject Author
Re: [gentoo-user] app-misc/ca-certificates Michael Orlitzky <mjo@g.o>