Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates to Certificate_and_Public_Key_Pinning.md #786

Open
MarkRGamache opened this issue Jul 7, 2023 · 5 comments
Open

Updates to Certificate_and_Public_Key_Pinning.md #786

MarkRGamache opened this issue Jul 7, 2023 · 5 comments

Comments

@MarkRGamache
Copy link

The need for pinning is driven by outdated criticisms of PKI. Since it was written, the industry has been forced to comply with the will of the CA Browser Forum and dictates by google, enforced by Chrome. This has led to a place where it is much harder to get a rouge certificate (CAA record enforcement) and much easier to detect them (CT Logs). All major browsers also handle revocation checking via fairly fast and robust out of band CRL distribution.

The HPKP failed experiment is proof that the availability risks of pinning are too high and real and that the controls above have made pinning largely unneeded. HPKP was well designed, allowing a list of pins and because it pinned keys and not certs, allowed for a yet to be used key to be pinned for later use when the cert was actually issued. Despite the good design, too many devs and ops teams shot themselves in the foot with it.

I'd like to propose that this doc be either labeled as legacy and suggest that pinning is not recommended anymore or massively updated in terms of threats and mitigations. I'd like to see it call out the risks more heavily and point out clearly when pinning does make sense.

The main goal is to change the perception that OWASP says you have to do this, as it is on many auditor checklists. Some are even taking it beyond the mobile space, which is troublesome.

I have already put in an Issue with the Cheat Sheet team on the topic so that if changes are made, the docs can be in sync.

Given the scope of change here, I assumed an issue was a better start than a PR which, out of context, might look like madness.

Thanks!

@kingthorin
Copy link
Contributor

It would be great to see this updated. It's not a topic I'm passionate about, so I don't have any great advice. Your points all seem reasonable to me, I'd be good with a total rewrite.

@mtesauro
Copy link
Contributor

mtesauro commented Jul 7, 2023

+1 on @kingthorin 's feedback. Would love to see @MarkRGamache make those changes.

@MarkRGamache
Copy link
Author

+1 on @kingthorin 's feedback. Would love to see @MarkRGamache make those changes.

Should I wait for any other feedback, or shall I work on a draft and put in a PR? I'd gladly held the community and myself on this. I've gained a lot of gray hair lately on this topic.

@kingthorin
Copy link
Contributor

Your call, I doubt there are many people watching this issue tracker.

@kwwall
Copy link

kwwall commented Jun 18, 2024

In #786 (comment), @kingthorin wrote:

Your call, I doubt there are many people watching this issue tracker.

Exactly why I am going to make an appeal for reviewers on the OWASP Leaders mailing list and OWASP Slack. I was waiting for the PR to be submitted to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants
@kwwall @mtesauro @kingthorin @MarkRGamache and others