search

OWASP / CheatSheetSeries

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.
https://cheatsheetseries.owasp.org
Creative Commons Attribution Share Alike 4.0 International
27.06k stars 3.79k forks source link

Update: Pinning Cheat Sheet #1428

Open MarkSRobinson opened 2 weeks ago

MarkSRobinson commented 2 weeks ago

What is missing or needs to be updated?

The current cheat sheet recommends certificate pinning. This is actually really bad from an operational sense because certificates have to be rotated out frequently. Currently all publicly signed leaf certificates have a maximum life of 397 days, and there is a proposal to drop this down to 90 days.

Most crypto systems change out the key on each renewal. Google is proposing to require all root certs to use new key data when refreshed. Keys also require replacement as recommend sizes gradually increases, and if there is a potential security breach all keys should be proactively rotated even if the key material has not been compromised.

Digicert recommends against certificate pinning.

Key pinning has generally caused problems than it solves as the inevitable key changes causes widespread breakages.

How should this be resolved?

Certificate pinning should be generally discouraged in the common case. If using the public root CAs does not provide enough security, people should use private CAs and have those root CAs distributed as needed.

szh commented 2 weeks ago

I agree that pinning should not be recommended for the majority of web applications. I think there's a place for it in specific instances where a high level of security is needed, but only when there is control of the client and server, so rotations can be properly handled on both ends (such as with client-server software where both are managed by an enterprise).

jmanico commented 2 weeks ago

I’m happy to warn about the dangers of pinning with stronger language. There are still use cases for pinning for very high risk sites and services.

kwwall commented 2 weeks ago

Just so you know, @markgamache and myself have been working on a PR for this which is an extensive rewrite and should address this. Mark has been in touch with both of the original authors (Jeffrey Walton and myself) and we've been working on this on and off since maybe end 3Q2023.

jmanico commented 2 weeks ago

I'm happy to hear this. Thank you @kwwall :)

markgamache commented 2 weeks ago

@MarkSRobinson FIWIW, I am slow, but am working in two halves of this. There is not only the cheat sheet, but a large doc on the threat model, rationale, and a bit of history that made pinning make sense in the past. I created Updates to Certificate_and_Public_Key_Pinning.md #786 to first update the threat model and yes, suggest that pinning creates a lot of risk and little reward. Expect that PR in a day or two. I also have an issue open for the cheat sheet. The intent is to first get the changes approved for the main document, and then do a PR that leads off with, read the threat model and probably don't pin. It will still have continent on how to do it if you must.

The main bits are PKI is much more secure now, due to the CABF, CT logs, CAA records, etc. Pinning was only ever meant for mobile, where one party controls the client and server. It also talks about how you would automate pin rotation if you really feel you must. The old guidance seemed to almost mandate pinning in the eyes of the reader and GRC types. The new should be, don't pin unless you reallllllly have to.

MarkSRobinson commented 2 weeks ago

@markgamache I would love to see it. I strongly support either marking it as legacy or severely revamping the doc emphasize the threat model.

markgamache commented 1 week ago

MarkSRobinson

The PR for the main page on pinning is pending. Content here https://github.com/markgamache/www-community/blob/new_branch/pages/controls/Certificate_and_Public_Key_Pinning.md