|
|
|
|
|
by stephenmac98
644 days ago
|
|
I didn't say a "pinned self signed cert is insecure" I said that self-signed certs are a lazy choice I also said "allowing the end-user to confirm a certificate offers basically 0 protection"
If an average user get's prompted to trust a certificate they will do so blindly
At most, someone might look at the subject, but it's 0 effort for a malicious actor to generate a self-signed cert with the same subject, which will be sufficient to fool a decent chunk of users Pinned certificates do relieve the above issue, but it is still a lazy choice that creates increased long term complexity in the configuration of multi-system environments
Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA
Using a CA also allows for use of CRLs or OCPS.
If you have 20 devices configured to trust a given self-signed certificate, and that certificate leaks, you now have to update all 20 devices to remove that trust. If you used a CA and implemented either a CRL or OCSP, then you only have to update the respective impelmentation and all of yoru clients will immediately stop trusting that certificate. In Summary:
Using an internal CA offers all the potential protections of pinned certificate, with a number of additional useful security options like OCSP or CRLs
Using Self signed certificates creates more work when handling certificate leaks or certificate rotation
Using a CA is the industry standard practice, I highly doubt there is a single outward facing project by a major company using a directly self-signed certificate.
BUT
A self signed certificate is lower effort on the initial setup Lazy |
|