Update: [Pinning_Cheat_Sheet.md]

[MarkRGamache]

What is missing or needs to be updated?

The doc is a bit too light on the why, when, and when not to pin. I regularly have to deal with folks who simply say, "OWASP says we have to pin". This is partly due to the issue being nuanced, but also due to lack of detail on the risks and rewards. Given modern controls, more often than not, the risks far outweigh the rewards. We have the data from the failed HPKP experiment. The plans and implementation at the browser level were well thought out, and one can do it will, but few got it right and too many teams shot themselves in the foot. Availability is an often-overlooked member of the CIA triad. I'd like to put a bit more focus on it in this cheat sheet.

Most of the docs that do cover this topic are very outdated. With DNS CAA records to act as a proactive control to stop rouge certs from being issued, and CT Logs to detect them, rouge certs are close to a thing of the past. There will always be gaps, but they have become very small.

Also, some docs seem to hint that this is only about mobile apps, but this is not clear enough and I see people wanting to pin for non-mobile.

How should this be resolved?

I'd love to see the doc explain that the landscape has changed, and how, and suggest that pinning is NOT recommended unless you meet very specific criteria. These would be around pub key distribution capabilities. Pinned in code and pushing new code is not a good way of doing this. Updating pins in real-time would happen over TLS, which presumably the developer doesn't trust, thus the need for pinning.

I'd love to have a short explainer and links to how CAA records are required to be checked by all public CAs before cert issuance and how all public CAs publish to CT Logs before certs are issued and can be monitored by everyone.

Ultimately, I'd like the tone of the article to be that pinning can be a useful control worth considering, when done well, but that it is not recommended due to the risks.

[szh]

I like your thinking. I'm curious what the other maintainers think. @mackowski @jmanico

[kwwall]

I'll add my $.02 even thought it wasn't asked for since Jeff Walton and I were the original authors of this (back when it was just a OWASP wiki page and before it was a cheat sheet.)

In general, I think pinning should be avoided. CT is usually good enough except for high-value applications that are on a platform that is not secured by something like corporate security. But if you are concerned by a surreptitious intercepting TLS proxy, it's either that or client certificates so pinning is probably a little easier. Generally, you would only do this on really important mobile applications though.

That said, setting up the pinning is the relatively easy part. Changing the certificate in advance of it expiring is the much harder part. I usually recommend having it expire every 3 to 5 years instead of the average 3 months or so (with Let's Encrypt certs) or annually for most other CAs. The tricky part is all too often there are going to be people who don't update their mobile apps until after it expires so you have to be prepared for that. If you can force updates (like Signal now does), you can update the certs chain at that time. But all too often, the GRC part of the business insists on "following things by the book" and that means that they insist on annual renewal of certificates and some don't even allow you to reissue the same pub/priv key pair so you have to generate a new CSR each time. (Usually that's because they are worried more about following the letter of their policy and they don't understand the technical challenges.) Of course certain regulatory or compliance issues may enforce a certain renewal period in which case you may not have a lot of options in that regard.

But at any rate, it's a huge PITA and many security people don't like it because it makes pen testing those apps with an intercepting proxy really difficult.

[szh]

Thanks @kwwall. So it sounds like you're pretty much in agreement with @MarkRGamache?

[kwwall]

Yes. Use it as a last resort.

…

-kevin

On Tue, Jul 11, 2023, 8:55 AM Shlomo Zalman Heigh ***@***.***> wrote: Thanks @kwwall <https://github.com/kwwall>. So it sounds like you're pretty much in agreement with @MarkRGamache <https://github.com/MarkRGamache>? — Reply to this email directly, view it on GitHub <#1165 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAO6PGYX4CHYQOT3JF2NJ3DXPVELRANCNFSM6AAAAAA2CCXHRQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[szh]

Great. @MarkRGamache do you want to submit a PR to change this?

[MarkRGamache]

Great. @MarkRGamache do you want to submit a PR to change this?

I will draft a PR and get it in. I will want it well considered and explain why, despite "Yes. Use it as a last resort.", so it will take a few days.

[MarkRGamache]

@kwwall Considering that this is a major rewrite, is there a precedent to archive the current doc to a place that can be referenced? I hate to shock readers this way, or is the git commit history good enough, despite not being good for officially referencing. I was actually mixed up and referring to updating this doc OWASP/www-community#786

[kwwall]

I personally am fine with just linking to the previous GitHub version via the Git history, although we probably want to refer to it as "the previous Pinning Cheat Sheet" and slap a link on that rather than just giving them a raw GitHub link. It out to render close-enough since it is in Markdown.

That said, I think the longer term problem is how long do we want to leave that old link around? Maybe that's something that we should decide up front so we can note that in the current cheat sheet.

Anyhow, just a thought. @mackowski @jmanico @szh - what do you think in that regard. I do believe there are likely going to be some radically different recommendations.

[szh]

I think linking to the old one in GH history is fine. Maybe we should keep the link around on the new version for a year or two?