Recommend supporting Certificate transparency as an alternative for pinning as L2

[commjoen]

As an alternative to pinning (so as a requirement next to pinning), have a requirement to support CTA (certificate transparency) validation, see:

• https://www.agnosticdev.com/blog-entry/network-security/mobile-landscape-certificate-transparency
• https://github.com/technion/ct_advisor
• https://github.com/google/conscrypt
• https://github.com/google/certificate-transparency-java
• https://www.agnosticdev.com/blog-entry/network-security/mobile-landscape-certificate-transparency
• https://github.com/Babylonpartners/certificate-transparency-android

Note: ios 12.1.1 requires it already.
https://chromium.googlesource.com/chromium/src/+/master/net/docs/certificate-transparency.md#certificate-transparency-for-enterprises for more info
NOTE: using CTA will require your domain (including internal domains) to be publicly registered which was made fun off by Jeroen Willemsen in https://xebia.com/blog/certshout-all-your-domains-are-public/, but oftne forgotten. So if you have a domain that you don't want to have that publicly available, you can pin, otherwise: consider CTA, but be aware that you need a CA that makes sure no weird shit happens with your cert.

[TheDauntless]

CTA does not provide protection against the typical mitm, only against wrongfully issued certificates by publicly trusted root CA's.

So it's not an alternative to pinning. I also don't know if we need to include this in the MASVS. iOS supports it by default, Android most likely will too, and I don't think you're quickly going to have this issue on mobile endpoints of a specific app.

[commjoen]

maybe we can say it is a defense in depth control? after all, it is nice to detect that the ca went rogue ^^. And it might be good enough for some to whitelist a bunch of ca's and then still handle the fact that the cA went rogue. Because sometimes availability is more important than confidentiality.

[commjoen]

Meeting notes:

• members will look at the internals and get back about it next meeting.

[commjoen]

Meeting notes:

• members will look at the internals and get back about it next meeting.

[cpholguera]

I agree with @TheDauntless , I don't see any additional requirement for the MASVS. It's covered by MSTG‑NETWORK‑3. And we could simply extend the MSTG‑NETWORK‑3 test case in the MSTG including yet another possible certificate validation check/method. From the MASVS req.: "Only certificates signed by a trusted CA are accepted." The MSTG can explain what does this mean in the context of CTA.

When doing so, we should highlight that the point of CTA is availability rather than confidentiality, as @commjoen pointed out.

[sushi2k]

Agree with Carlos and Jeroen. A requirement about CTA in the MASVS might be too much, but putting it into the MSTG as part of an existing test case, makes the most sense.

[commjoen]

MEeting notes:

• expand MSTG-Network-3 with CTA for both Android and iOS.

[commjoen]

Further taken care of in OWASP/owasp-mastg#1492