Hacker News Reader

Comment by mmd45 | Hacker News Reader

explain how a pinned self signed cert is insecure. i don't see it. it would seem to be more secure than one signed by a public CA that's not pinned.

View on HN

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

for the use case of a single user IMAP server this is all way, way, too complicated and buys you nothing in terms of security. it's completely analogous to why we dont use CAs to validate openssh host certificates.

Yes it's a analogous using CA is still a higher bar, but it would arguably be better to also use CA to validate openssh host certificates for all the reasons he listed above.

So maybe we should ask ourselves why can't we just figure out a way to improve handling of CA? Thanks to Let's Encrypt https coverage dramatically improved, now is maybe the time for more people to switch to self CA.

I agree though that promoting adoption through good tooling and pedagogy would be a nicer approach than Apple slap on the wrist.

You need to calm down and take a step back to realize not everyone needs to support 20 devices or even 2. What you’ve suggested is a ridiculous blanket statement assuming everyone is setting up things for a fleet of clients.

It really only is for bad practical reasons, that all coincidentally make it harder and harder to self-host stuff locally without paying a few dollars a month or year here and there to various rent seekers.

"Just use Letsencrypt" really is the correct answer for 99% of use cases, but good luck if you find yourself with one from the 1%. You'll get an army of people mindlessly parroting "best practices" and will assume you're incompetent/lazy if you can't find a way to make them work for you.

Internal CAs and self signed certificates are different. You can still generate a CA, sign your certificates, import your own CA into your phone and have that verify your certificates. You don't need Letsencrypt. But you'll learn in time.

Thanks for the condescension, but I know how to do all of this. I've done it before. And because of that, I can first hand attest that it's way too complicated.

No non-sophisticated user is able to run their own local CA, and that's why their NAS, IoT setup etc. all run over HTTP only, which in turn has implications for available web APIs (thanks to "secure origin only" policies and no exemption for local IPs/zeroconf domains) and many other things.

It also doesn't work for at least modern Android apps, since Android no longer makes user-provided CA certificates available to (non-browser) apps anymore, I believe, unless they're compiled with a special debugging parameter. On iOS it's still possible, but I'm not sure how long it's going to stay that way.

If a user set up a NAS they should be capable of googling

"Openssl how to set up a CA" > First link fully explains it https://arminreiter.com/2022/01/create-your-own-certificate-...

"How to import CA into iPhone" > First link fully explains it https://www.ibm.com/docs/en/mpf/7.1.0?topic=certificates-ins...

"Android app customize trusted CAs" > First link fully explains it https://developer.android.com/privacy-and-security/security-...

The barrier to entry on PKI isn't that it's hard, it seems to be that people just can't be bothered, PKI is among the most google-able tech processes out there

Setting up a NAS means buying one on Amazon and plugging it in.

You're completely out of touch with the majority of the userbase of these products if you think even one in 10 NAS users will set up their own CA using OpenSSL (in a secure way that doesn't expose themselves to being MITMed even on public sites such as that of their bank down the road).

In that case the NAS company should, at a minimum, be loading their NAS with a certificate signed by a CA owned by the NAS company, where the trust chain for their NAS's certificates are easily available for users to grab and install.

In an ideal world they would load a letencrypt certificate and set up the tooling required to automatically pull down a new one when required.

A NAS company owned CA doesn't offer much of a benefit directly for the plug-n-play users, but it's still better than just a self signed cert, and for people who care about their security even a little bit it can significantly protection.

Most Plug-n-Play NAS solutions will integrate with a web api and/or an app, and it's more common than it should be that NAS'es are exposed to the internet.

Once you control both the NAS and it's clients, there's absolutely no reason not to preload a complete PKI implementation. Even just an installation app which loaded the chain onto any device you wanted to interact with the NAS would be sufficient.

If NAS'es are intended for non-technical people, then any NAS sold should be secure by default.

My point is precisely that current browsers and OSes make it impossible to ship a secure-by-default device running a local web server, NAS or otherwise.

Requiring users to install a globally trusted CA is a disaster from a security point of view (now my NAS vendor or anyone that hacks them can pose as google.com!), and for this reason doesn’t even work with modern Android apps anymore, for example.

Offering a layperson NAS buyer a self-signed cert is not "secure by default" even if browsers did accept it.

Would it be less secure than unencrypted HTTP?

No.

But if you want "secure by default" then neither one is acceptable.

How? An internal CA is just a self-signed certificate that you’ve told your device to trust; and to trust other certificates signed by it.

Somewhere you still need to trust a self-signed certificate.

You can guard the root certificate better than the leaf certificate. For example, you can keep it offline in an air-gapped environment.

Reply on news.ycombinator.com