Dear m.d.s.p.,

I would like to bring into discussion the use of certificate/public key pinning 
and the impacts on the 5-days period for certificate revocation according to BR 
§4.9.1.1.

Recently, we (Multicert) had to rollout a general certificate replacement due 
to the serial number entropy issue. Some of the most troubled cases to replace 
the certificates were customers doing certificate pinning on mobile apps. 
Changing the certificate in these cases required configuration changes in the 
code base, rebuild app, QA testing, submission to App stores, call for 
expedited review of each App store, wait for review to be completed and only 
then the new app version is made available for installation by end users (which 
is turn are required to update the app the soonest).

Meeting the 5-days deadline with this sort of process is “challenging”, at best.

A first approach is to move from certificate pinning to public key pinning 
(PKP). This prevents the need to update the app in many of the certificate 
replacement operations, where the public key is reused and the certificate can 
be replaced transparently to the app (generically, an “User Agent” doing PKP).

However, in the event of a serious security incident that requires re-key (such 
as key compromise), the certificate must be revoked in less than 24 hours (for 
the benefit of everyone – subscriber, relying parties, issuing CA, etc). It’s 
virtually impossible to release a new app version within this timeframe. And 
this, I think, make a very strong point against the use of PKI.

On the other side, PKP is a simple yet powerful and effective technique to 
protect against MITM and other attacks. It seems to be widely used in apps with 
advanced threat models (mobile banking, sensitive personal information, etc) 
and there are many frameworks available (including native support in Android 
via Network Security Configuration [1]).

There are several possible mitigation actions, such as pinning more than one 
public key to have more than one certificate to quickly rollover in case of a 
revocation. Even then, it is very likely that all the redundant key pairs were 
generated and maintained by the same systems and procedures, and thus all of 
them will become effectively compromised.

Ultimately, it may become common practice that 1) PKP frameworks are set to 
bypass revocation checks or 2) PKP is done with private certificates (homemade, 
self-signed, managed ad-hoc with no CRL/OCSP services). Does any of this leads 
to a safer Internet?

I don’t expect this thread to end up into an absolute conclusion advocating for 
or against, but opening it to discussion and contributions may help to document 
possible strategies, mitigations, alternatives, pros & cons, and hopefully 
provide guidance for an educated decision.

Best regards,

Nuno Ponte
Multicert SA

[1] https://developer.android.com/training/articles/security-config 

 



_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to