Hacker News Reader

Comment by dcow | Hacker News Reader

Cert pinning is an anti-pattern. No need for the CA infrastructure if you're going to bypass the CA infrastructure. If you control the software on both sides, which is required for cert pinning, then you can use self-issued certs. Also: roll your certs frequently.

Shameless plug for https://smallstep.com/cli which makes the process of issuing and rolling certs (incl. client certs for mutual TLS) easy enough to be workable in a modern application.

View on HN

I totally agree: pinning to a single CA is super-fragile and a terrible idea, and if you don't have a need for public certs, doing a proper private PKI (Small-step is a good choice here!) is a good place to go as long as you can run it properly.

However, whether you're running your own or pulling public certs, you should go into any PKI setup assuming you'll need to change out all the certs at some point. If you're going private, make sure you have a mechanism to replace everything--yes, including that private root you just created!--in a safe and secure fashion. Preferably, that would include some manner of doing so that doesn't involve blowing everything up and leaving existing clients high and dry...but that's a business decision to make.

If you're going with public certs, you still have to make that assumption. I see too many developers still pinning trust to a single root CA like Let's Encrypt or GoDaddy and then being stuck when the CA in question is revoked, replaced, expires, or is booted out of public trust, or just because their business insists they use something different. The solution to this is a trust store, which you can make as minimal as you want to: pick two or three public root CAs, stick them in a blob, and tell your app to accept nothing else. That leaves you an out, for the next time the cert industry has a Symantec-like event and everyone has to get off that train right away, since you can move from one of those to another one without having to change anything in the app.

How does using a self-issued cert address the concern of mitm proxying? (specifically, a user intercepting their own traffic to reverse engineer the api/protocol)

You create a Root Self Signed Certificate, and then deploy leaf certs signed by that root to your API.

Then deploy your client apps with the certificate of your self signed root.

Assuming that your root is safe, no attacker will be able to generate a cert that will be accepted by your client.

That doesn't make sense to me, sorry. Got an article or something?

Don't have an article on hand :/ just something that I've played around over with over time.

Which part is confusing? Maybe I can try to clarify/give examples where helpful.

I think you're maybe talking about an adversarial MITM. I'm talking about someone trying to reverse engineer your API by intercepting their own traffic

The confusion here might be around the term "self-signed". Technically, all roots are self-signed—that's the definition of a root CA!—but in this case the user just means "self-signed" as in "signed by me, not signed by some commercial third party". "Self-signed certificates", though, usually refer to certificates with no PKI chain: the device created a single certificate, signed it with its own key, and then just distributes it to create trust without the usual hierarchy of a PKI.

The attack on that latter system is that you as the client have no basis on which to trust that cert when its first presented. So an attacker who can intercept that first presentation of the certificate and replace it can MITM the traffic flow without you knowing. Worse, most devs "fix" that initial trust problem by telling the client not to validate the cert when its presented (because they wouldn't have any basis for doing that anyway), so an attacker is free to inject their own cert into the traffic at any time.

Using an actual private PKI hierarchy helps fix this: you create a root, and get your clients to trust only that root. Now you can issue your own certs, and an attacker can't MITM the traffic unless they can get their own cert from your CA. That's the same model as is used with commercial CAs: you're just operating the root of the chain yourself instead of paying someone else to do it.

But isn't this exactly why certificate pinning is needed... Sure I can roll my own PKI and install the Root CA on the client devices, but they can still intercept their own traffic by installing their own trusted Root CA.

If the TLS client isn't a webbrowser, it doesn't have to use the list of trusted roots provided by the underlying system (be it OS or browser).

Certificate Pinning is the solution you'd look to if you have a clients that cannot securely ship with root certificates/cannot pick the root certificates they will use to validate a certificate when initiating a TLS connection.

Edit: I should add that I am not a mobile developer, so I don't actually know if the 'bring your own root CA' method is supported by the corresponding TLS libraries. But I know that this is possible 'in general'

I missed the parenthetical on your comment, my apologies. You're right: if you can monkey around with things enough to SSL-proxy the traffic, then rolling your own PKI will not help prevent that. What will help prevent that, yes, is pinning, but my argument above was that pinning to any single CA (or worse, any single leaf certificate) without a mechanism for replacement is what gets people into trouble. Selecting a small set of trusted CAs is a much stronger pattern, and would preserve the inability of clients to swap out their own certs or proxy their own traffic (although it may also break things—Google had to bend on that one a bit to allow for enterprise SSL decryption, e.g.).

Not entirely accurate. Your client software builds a TLS client with your sole private trusted root. Nobody can MITM with a self signed cert unless they can reverse your client (or system) enough to hook the TLS stack, which there are numerous tools out there to do which is also why (but also irrespective of the fact) IMHO the "zomg we must prevent the user from seeing _their_ traffic" is a totally bogus pursuit. However, if you're dead set on thwarting some subset of the script kiddies, then mTLS is your friend because it's a real solution to the "I want to authenticate my client (perhaps because only it should see the traffic)" problem.

Because you control the client software so you just make a TLS client that has only your root trust anchor. This is exactly the same as CA/pubkey pinning from a threat model perspective.

OpenBSD does something like this. In the current release, they provide the public keys for the next release. After trust-on-first-use it's a never-ending cycle.

I call it trust-on-first-use because I didn't verify the initial signatures. Hmmm..

Reply on news.ycombinator.com