Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running one’s own root Certificate Authority in 2023

wejn.org

Post reply on HN
Print view View original

71–80 of 164 posts

Re: Running one’s own root Certificate Authority in 2023

#71

Post by bombcar »

jiggawatts wrote: post #64
Nextgrid wrote: post #61

Earlier quoted context omitted.

The main advantage is that this CA and all downstream certificates would be globally-trusted (limited to the domain), which is not the case for a custom CA. Security-wise it shouldn't be any worse than wildcard certificates which are already a thing. It would actually improve things, because the user can now issue downstream certificates much more granularly without having to interact with the root CA (so you can iss…

It would improve things for everybody but the certificate authorities. They're selling something with a marginal cost of zero for $50 each. A wildcard certificate costs more not because it is materially different or "harder" to issue, but because it replaces many $50 certificates. Thus, it "must" cost more, or everybody would just use wildcard certificates everywhere and reduce profits at the large public CAs. It is…

Hopefully let’s encrypt continues to put the pressure on them so eventually the other cert authorities start offering things worth paying for.

Re: Running one’s own root Certificate Authority in 2023

#72

Post by ivlad »

sneak wrote: post #59
fiddlerwoaroof wrote: post #45

Earlier quoted context omitted.

The other advantage of running your own PKI is you can intercept and decrypt arbitrary traffic on the network.

No. Knowledge of the CA private key does not allow for this. In all cases you have the webserver's private key, whether you issue the cert yourself or if someone else does. If you have the web server's private key, you can decrypt the traffic, but only if PFS ciphers are not used. It is a common misconception that knowledge of CA keys allows you to decrypt traffic. It does not. It allows you to issue valid certificat…

> Knowledge of the CA private key does not allow for this

Of course it does. You just generate certificates for every TLS handshake you see and MitM them.

And yes, it works for PFS too. There is no difference for MitM.

> In the case of PFS cipher suites (eg EDH) an ephemeral key is used for confidentiality and the endpoint keys are just used for integrity and key authentication. Even with the webserver key you aren't decrypting those streams.

You never encrypt data with a key from certificate, even without PFS. That would be too slow. You generate a pre-master key and then use it to generate keys for symmetric algorithms, like AES or Chacha20, that are actually used for data stream encryption. The only difference between PFS and non-PFS is that in the former case pre-master is generated using some form of DH, with promise of keys being destroyed after some time, and in the later case, client just generates a random key, encrypts it with the public key and sends it to the server.

Re: Running one’s own root Certificate Authority in 2023

#73

Post by ivlad »

Using RSA in 2023 for a CA that is expected to be around for an extended period of time is just silly.

ECDSA 384 or longer depending on the expected CA lifetime and security margins (see https://www.keylength.com/) is a saner choice.

Also, https://blog.trailofbits.com/2019/07/08/fuck-rsa/

Re: Running one’s own root Certificate Authority in 2023

#75

Post by sneak »

ivlad wrote: post #72
sneak wrote: post #59

Earlier quoted context omitted.

No. Knowledge of the CA private key does not allow for this. In all cases you have the webserver's private key, whether you issue the cert yourself or if someone else does. If you have the web server's private key, you can decrypt the traffic, but only if PFS ciphers are not used. It is a common misconception that knowledge of CA keys allows you to decrypt traffic. It does not. It allows you to issue valid certificat…

> Knowledge of the CA private key does not allow for this Of course it does. You just generate certificates for every TLS handshake you see and MitM them. And yes, it works for PFS too. There is no difference for MitM. > In the case of PFS cipher suites (eg EDH) an ephemeral key is used for confidentiality and the endpoint keys are just used for integrity and key authentication. Even with the webserver key you aren't…

MitM is not "intercept and decrypt arbitrary traffic on the network" which is what was asserted. You are describing an active attack, while fiddlerwoaroof was discussing a passive one.

Re: Running one’s own root Certificate Authority in 2023

#76

Post by mdekkers »

jiggawatts wrote: post #62
diarrhea wrote: post #58

Earlier quoted context omitted.

A password is a secret. A certificate is fully public (it’s useless if not). I don’t see how they’re similar in that dimension. Or how certificates are possible without a third party (a core reason for all the ceremony). Passwords get away with not needing a third party involved because they’re a prearranged process. Certificates aren’t, I need to be able to hit any website at any point, for the first time.

The key phrase here is internal use . Think authentication between two micro services, not HTTPS for someblog.com. The third party in this case is just a file: the internal CA key. Try to think of this in the following terms: the issued certs are just signed tokens , nothing more. They’re also conveniently a public-private key pair, but that’s not the point. The point is that if you used a 1kb random password for ser…

> The point is that if you used a 1kb random password for service to service auth and someone tried to sell you a $400/mo service to generate them, you’d laugh in their face and then have security escort them from the building.

Go ahead, run an internal secret store that issues properly trustworthy internal certificates. It isn’t hard, but neither is it cheap not. You oversimplify and gloss over a few _really_ important aspects of why and how certificates work. A certificate _acting like a password_ in some cases doesn’t mean it actually _is_ a password, and if you don’t really need the additional functionality to the point where the cost outweighs the delivered value, you are using the wrong tool for the job.

Running a CA is not at a technical challenge. Running a _trustworthy_ (there is that word again) CA is process heavy and it involves quite a few people doing work on a regular basis, and without those processes you may as well just something else - like an untrusted CA, or some kind of token issuing service (which, shockingly, also costs money to run properly).

A few really good options around DIY CAs were mentioned in this discussion, smallstep is pretty good for example. Nothing (except possibly your $org’s security policies) prevents you from throwing that up somewhere and start vending certs.

The fact that it is an internal CA to be used for internal purposes makes no difference, unless you believe that “everything internal is trusted because it is internal” in which case many other discussions on a very wide variety of subjects is due.

Re: Running one’s own root Certificate Authority in 2023

#77

Post by mdekkers »

jiggawatts wrote: post #43

“Cultural” technical issues are so frustrating to me. A certificate is fundamentally just a type of credential, like a password, but for historical reasons they’re treated like getting citizenship papers. There’s always this ceremony even in scenarios where it makes zero sense — such as internal-use certificates used for a gRPC API server behind a load balancer. Why - for the love of God why - can’t I just obtain a c…

> Ceremony is required.

Ceremony, as in “a well established, rigorously implemented, meticulously documented, and diligently audited process” is required to establish and maintain trust. A CA promises that folks showing up bearing their certificate _are who they say they are_ - this doesn’t mean it is perfect (there are plenty of cases where public CAs went wrong) and some random person can place their trust in that assertion.

The whole _point_ of a PKI is trust, and why would this be any different for internal systems?

Re: Running one’s own root Certificate Authority in 2023

#78

Post by [deleted] »

ivlad wrote: post #73

Using RSA in 2023 for a CA that is expected to be around for an extended period of time is just silly. ECDSA 384 or longer depending on the expected CA lifetime and security margins (see https://www.keylength.com/ ) is a saner choice. Also, https://blog.trailofbits.com/2019/07/08/fuck-rsa/

[deleted]

Re: Running one’s own root Certificate Authority in 2023

#79

Post by fiddlerwoaroof »

sneak wrote: post #75
ivlad wrote: post #72

Earlier quoted context omitted.

> Knowledge of the CA private key does not allow for this Of course it does. You just generate certificates for every TLS handshake you see and MitM them. And yes, it works for PFS too. There is no difference for MitM. > In the case of PFS cipher suites (eg EDH) an ephemeral key is used for confidentiality and the endpoint keys are just used for integrity and key authentication. Even with the webserver key you aren't…

MitM is not "intercept and decrypt arbitrary traffic on the network" which is what was asserted. You are describing an active attack, while fiddlerwoaroof was discussing a passive one.

I wasn’t distinguishing the two sorts of attacks.

Re: Running one’s own root Certificate Authority in 2023

#80

Post by m1keil »

ivlad wrote: post #73

Using RSA in 2023 for a CA that is expected to be around for an extended period of time is just silly. ECDSA 384 or longer depending on the expected CA lifetime and security margins (see https://www.keylength.com/ ) is a saner choice. Also, https://blog.trailofbits.com/2019/07/08/fuck-rsa/

Makes no difference in his setup as he can rotate the CA and the rest of the infrastructure quickly.
Post reply on HN