[Owasp-leaders] Certificate pinning - what do you think?

Tudor Enache Owasp tudor.enache at owasp.org
Thu Nov 5 12:40:03 UTC 2015


Hi,

When heartbleed happened people changed their certs because their private keys were leaked, which means that they generated a new public private key pair, which implies that the public key changed as well (due to the mathematical relationship used in their generation) which means that both 1 and 2 methods of pinning are ineffective when the cert needs to be changed in case of heartbleed or private key compromise.

I am not an expert in pinning, but this article can help you:
https://timtaubert.de/blog/2014/10/http-public-key-pinning-explained/
It basically says that you could also pin the public keys in the trust chain as a backup plan until you deploy the update to your mobile apps in case the cert needs to be urgently changed.
Obviously you will still be exposed if the MITM hacker issuesa cert with the same CA and trust chain but you will at least avoid bricking the app in the time window until you push the update with the mew public key.

Hope I made sense

Tudor

> On 05 Nov 2015, at 15:40, Gary Robinson <gary.robinson at owasp.org> wrote:
> 
> Hi Mike,
> 
> The page you mention describes two ways to pin:
> 
> 1) Pinning (effectively) on the fingerprint of the server certificate
> 2) Pinning on the public key
> 
> If you pin on 1) then the pinning is specific to that one certificate, and as you say, if the cert needs to get changed in an emergency then you are in difficulty (as many people saw with the HeartBleed issue).
> 
> If you pin on 2) then *any* certificate the server creates with the corresponding private key will still work.  This allows your client to still accept an update/new cert as long as the same private key was used to sign the cert request.
> 
> IMO 2) is more flexible as it allows cert upgrades when using the same private key.  If you or your client has strict rules around private key lifetimes, or rules preventing a private key being used to request more than 1 cert, then this needs to get looked at.
> 
> If you had to use option 1), then the only way I see to be flexible is to simply order 2 or 3 certificates and put each of those fingerprints into the client pinning check.  You'd start off using the first cert (with other certs in some offline backup) and if/when that first cert gets compromised, you start using the 2nd cert.  It'd cost x2 or x3 the price, but will offer redundancy.
> 
> Gary
> 
>> On Thu, Nov 5, 2015 at 11:22 AM, Mike Goodwin <mike.goodwin at owasp.org> wrote:
>> Hello all,
>> 
>> I'm looking for some advice on certificate pinning. At first, I thought it was a good idea, but now I'm having second thoughts about it. The OWASP guidance on it is here:
>> 
>> https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
>> 
>> In the "when do you pin?" section on that page it gives strong guidance:
>> 
>> "You should pin anytime you want to be relatively certain of the remote host's identity or when operating in a hostile environment. Since one or both are almost always true, you should probably pin all the time."
>> 
>> However, I am concerned about the practical, operational aspects of this. If you have to change your server certificate in a hurry, say because you think it has been compromised, or maybe just because someone who has had access to your private key is leaving your organisation, how do you do this without disabling all your clients.
>> 
>> I get that your client can store a list of pinned certificates, not just one, but this only works in planned scenarios such as routine certificate expiry. I don't see how it helps in "emergency situations". And even in planned situations, if it is not quick and easy to update all client applications, then you might still end up with clients unable to connect.
>> 
>> So we will end up making a choice between keeping a compromised certificate and locking out valid users.
>> 
>> Overall, I am worried that in a real world setting, pinning will do more harm than good.
>> 
>> Any expert opinions would be very welcome!
>> 
>> Best regards,
>> 
>> Mike
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> 
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20151105/91400351/attachment.html>


More information about the OWASP-Leaders mailing list