SSL Pinning not a best practice anymore for Android Apps
sushi2k opened this issue · comments
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)
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 dangerous job to do and that you need multiple backup pins if you do this. So having it as an L2 with multiple backup pins could still be recommendation ^^. But in the end it gets just as hard as payload encryption with all the confusion on the subject, so therefore it could be removed as well.
Maybe a good idea to migrate towards CT support :) ?
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."
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:
- Do not pin against endpoints where you do not own the Certificate (dangerous)
- @commjoen You are right, as long as you are in the possession of the CSR and pin against the public key, using another CA will have no impact.
Certificate Transparency is also something that we do not describe yet in the MSTG that, see also: OWASP/owasp-mastg#1492
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)
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!