-
See: https://owasp.slack.com/archives/C1M6ZVC6S/p1619646553041600 URL: https://developer.android.com/training/articles/security-ssl#Pinning ioXT (where Google is also part of) is still suggesting it (as they are also based on the MASVS) |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments
-
Note that the website warns about Certificate pinning and tells about issues of when a CA changes a. Public key pinning does not involve either of those strategies. It says it is a very |
Beta Was this translation helpful? Give feedback.
-
Maybe a good idea to migrate towards CT support :) ? |
Beta Was this translation helpful? Give feedback.
-
Like julep from slack was saying, "It looks to me that it warns not to pin endpoint that you do not control. For example, someone may decide to pin some third-party public endpoint. And that is clearly a bad idea." |
Beta Was this translation helpful? Give feedback.
-
Thank you all for the feedback! We should make this more clear in the MSTG what is and what is not dangerous when using SSL Pinning, like:
Certificate Transparency is also something that we do not describe yet in the MSTG that, see also: OWASP/owasp-mastg#1492 |
Beta Was this translation helpful? Give feedback.
-
We could indeed make this clearer that pinning on 3rd party endpoints is a bad idea, but since it's a Level 2 the organization should be capable of properly managing their certificate lifecycles etc. Also, Certificate Transparency only protects against a compromised public root certificate. It does not protect against mis-issued certificates from non-public root CA's. With later Android the chance of an app trusting user certificates is of course lower, but there are always still apps that do it. (And, CT is reactive, while certificate pinning is proactive) |
Beta Was this translation helpful? Give feedback.
-
Hey all, wanted to offer further perspective here based on the recent conversations I've had re: Cert Pinning from Google and ioXt. To clarify, the ioXt requirement around certificate pinning is there with the intent to prevent using an untrusted CA or as mentioned above, a certificate from an endpoint which you do not own. Google's Dev guidance is warning that certificate pinning is a complicated procedure, especially with more complex architectures. It is, however, still a recommended practice, especially at the L2 level. What is of particular concern is pinning a leaf certificate vs pinning a root or intermediate level certificate; and that leaf is what's particularly "dangerous". This article, albeit a bit old, is fantastic at explaining this: https://appmattus.medium.com/android-security-ssl-pinning-1db8acb6621e Please let me know if you need any help with the updates to the MSTG or review any changes. I'd be happy to assist! |
Beta Was this translation helpful? Give feedback.
Hey all, wanted to offer further perspective here based on the recent conversations I've had re: Cert Pinning from Google and ioXt.
To clarify, the ioXt requirement around certificate pinning is there with the intent to prevent using an untrusted CA or as mentioned above, a certificate from an endpoint which you do not own. Google's Dev guidance is warning that certificate pinning is a complicated procedure, especially with more complex architectures. It is, however, still a recommended practice, especially at the L2 level. What is of particular concern is pinning a leaf certificate vs pinning a root or intermediate level certificate; and that leaf is what's particularly "dangerous". This…