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

Jim Manico jim.manico at owasp.org
Wed Nov 11 20:41:39 UTC 2015


Tobias,

The main resources on certificate pinning at OWASP are:

 https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
and
https://www.owasp.org/index.php/Pinning_Cheat_Sheet

If you or anyone seed any errors in these guides please let me know!

Thanks all,
--
Jim Manico
Global Board Member
OWASP Foundation
https://www.owasp.org
Join me in Rome for AppSecEU 2016!

> On Nov 11, 2015, at 11:19 AM, Tobias <tobias.gondrom at owasp.org> wrote:
> 
> Just a few quick comments about key pinning:
> (see also RFC 7469 on key pinning for that: https://tools.ietf.org/html/rfc7469, which we (as in the IETF websec WG) published earlier this year.)
> - yes, pinning to a certificate higher up in the chain (e.g. root certificate) can be advantageous.
> - keep in mind that you could pin to more than one certificate. (see also RFC 7469)
> - if you do key pinning you might consider an update mechanism. In case of mobile apps you could consider to update the pins using the normal mobile app update.
> Best regards, Tobias (former IETF websec WG chair, the WG is successfully finished and closed now)
> 
> 
>> On 06/11/15 00:01, Tim wrote:
>> Yes, this is how we should approach certificate pinning and this is
>> how we should be recommending it to the public at large.  Simply make
>> your app trust only certificates signed by a particular CA that is
>> completely under your control.  This should be easy to do in any API
>> that allows the coder to specify what file/directory holds the CA
>> certificate store.  Pinning to a specific certificate is problematic
>> for the reasons described.  There are reasons the SSL PKI was designed
>> the way it was.  It isn't perfect, but you can leverage the features
>> that already exist.
>> 
>> tim
>> 
>> 
>>> On Thu, Nov 05, 2015 at 12:47:10PM +0000, Rogan Dawes wrote:
>>> You can also pin the certificate that signed your certificate, on the
>>> premises that your chosen ca is unlikely to issue a certificate for your
>>> domain to someone else.
>>> 
>>> That protects you from the case where a different CA issues a cert,
>>> including the case where that CA is one under your own control, ie. I load
>>> the Burp or ZAP CA into my browser key store.
>>> 
>>> Those certificates are valid for a much longer time period, so you can be a
>>> lot more confident that you will be able to issue a new version of your app
>>> before expiry becomes an issue. If you are really concerned about it, you
>>> could possibly chose a second CA as an alternate in case you have to switch
>>> for some reason. That does open the window a little, but it is still
>>> unlikely that that specific second CA will issue an invalid cert for your
>>> domain.
>>> 
>>> Rogan
>>> 
>>>> On Thu, 5 Nov 2015 05: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
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> 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/20151111/d5dfbe32/attachment-0001.html>


More information about the OWASP-Leaders mailing list