Hacker News Reader

> everyone will be so used to certificates changing all the time, and no certificate pinning anymore, so the day were China, a company or whoever serve you a fake certificate, you will be less able to notice it

I'm a computing professional in the tiny slice of internet users that actually understands what a cert is, and I never look at a cert by hand unless it's one of my own that I'm troubleshooting. I'm sure there are some out there who do (you?), but they're a minority within a minority—the rest of us just rely on the automated systems to do a better job at security than we ever could.

At a certain point it is correct for systems engineers to design around keeping the average-case user more secure even if it means removing a tiny slice of security from the already-very-secure power users.

>As I said in another thread, basically that will kill any possibility to do your own CA for your own subdomain.

like, private CA? All of these restrictions are only applied for certificates issued under the webtrust program. Your private CA can still issue 100 year certificates.

Let's suppose that I'm a competitor of Google and Amazon, and I want to have my Public root CA for mydomain.com to offer my clients subdomains like s3.customer1.mydomain.com, s3.customer2.mydomain.com,...

If you want to be a public root CA, so that every browser in the world needs to trust your keys, you can do all the lifting that the browsers are asking from public CAs.

Why do you want this when there are wildcard certificates? That's how the hyperscalers do it as well. Amazon doesn't have a separate certificate for each s3 bucket, it's all under a wildcard certificate.

Amazon did this the absolute worst way - all customers share the same flat namespace for S3 buckets which limits the names available and also makes the bucket names discoverable. Did it a bit more sanely and securely at Cloudflare where it was namespaced to the customer account, but that required registering a wildcard certificate per customer if I recall correctly.

The only consideration I can think is public wildcard certificates don't allow wildcard nesting so e.g. a cert for *.example.com doesn't offer a way for the operator of example.com to host a.b.example.com. I'm not sure how big of a problem that's really supposed to be though.

No. Chrome flat out rejects certificates that expire more than 13 months away, last time I tried.

Certificate pinning to public roots or CAs is bad. Do not do it. You have no control over the CA or roots, and in many cases neither does the CA - they may have to change based on what trust-store operators say. Pinning to public CAs or roots or leaf certs, pseudo-pinning (not pinning to a key or cert specifically, but expecting some part of a certificate DN or extension to remain constant), and trust-store limiting are all bad, terrible, no-good practices that cause havoc whenever they are implemented.

Ok, but what's the alternative?

Support for cert and CA pinning is in a state that is much better than I thought it will be, at least for mobile apps. I'm impressed by Apple's ATS.

Yet, for instance, you can't pin a CA for any domain, you always have to provide it up front to audit, otherwise your app may not get accepted.

Doesn't this mean that it's not (realistically) possible to create cert pinning for small solutions? Like homelabs or app vendors that are used by onprem clients?

We'll keep abusing PKI for those use cases.

I think if you're going to pin, pin to something you control. If it's an API endpoint, you can use a private CA and have the app trust your root, and pin to that. Same end result, but you're not going to be stuck if a third-party you have nothing to do with decides that some part of the hierarchy needs to change.

That's the exact opposite of what I'm referring to.

There is a client that has a self hosted web service. Or a SaaS but under his own domain.

There is a vendor that provides nice apps to interact with that service. Vendor distributes them on his own to stores, upgrades etc.

Clients has no interest in doing that, nor any competencies.

Currently there is no solution here: Vendor needs to distribute an app that has Client's CAs or certs built in (into his app realese), to be able to pin it.

I've seen that scenario many times in mid/small-sized banks, insurance and surrounding services. Some of these institutions rely purely on external vendors and just integrate them. Same goes for tech savvy selfhosters - they often rely on third party mobile apps but host backends themselves.

> 47 [is?] arbitrary, but 1 month, + 1/2 month, + 1 day are not arbitrary values...

Not related to certificates specifically, and the specific number of days is in no way a security risk, but it reminded me of NUMS generators. If you find this annoyingly arbitrary, you may also enjoy: <https://github.com/veorq/numsgen>. It implements this concept:

> [let's say] one every billion values allows for a backdoor. Then, I may define my constant to be H(x) for some deterministic PRNG H and a seed value x. Then I proceed to enumerate "plausible" seed values x until I find one which implies a backdoorable constant. I can begin by trying out all Bible verses, excerpts of Shakespeare works, historical dates, names of people and places... because for all of them I can build a story which will make the seed value look innocuous

From http://crypto.stackexchange.com/questions/16364/why-do-nothi...

> As I said in another thread, basically that will kill any possibility to do your own CA for your own subdomain

Only if browsers enforce the TLS requirements for private CAs. Usually, browsers exempt user or domain controlled CAs from all kinds of requirements, like certificate transparancy log requirements. I doubt things will be different this time.

If they do decide to apply those limits, you can run an ACME server for your private CA and point certbot or whatever ACME client you prefer at it to renew your internal certificates. Caddy can do this for you with a couple of lines of config: https://caddyserver.com/docs/caddyfile/directives/acme_serve...

Funnily enough, Caddy defaults to issueing 12 hour certificates for its local CA deployment.

> no certificate pinning anymore

Why bother with public certificate authorities if you're hardcoding the certificate data in the client?

> Instead of having closed systems, readonly, having to connect outside and update only once per year or more to update the certificates, you will have now all machines around the world that will have to allow quasi permanent connections to random certificate servers for the updating the system all the time.

Those hosts needed a bastion host or proxy of sorts to connect to the outside yearly, so they can still do that today. But I don't see the advantage of using the public CA infrastructure in a closed system, might as well use the Microsoft domain controller settings you probably already use in your network to generate a corporate CA and issue your 10 year certificates if you're in control of the network.

> everyone will be so used to certificates changing all the time, and no certificate pinning anymore

Browser certificate pinning is deprecated since 2018. No current browsers support HPKP.

There are alternatives to pinning, DNS CAA records, monitoring CT logs.

Cert pinning is a very common practice for mobile apps. I'm not a fan of it, but it's how things are today. Seems likely that that will have to change with shorter cert lifetimes.

If you're in a position to pin certs, aren't you in a position to ignore normal CAs and just keep doing that?

42