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

Tobias tobias.gondrom at owasp.org
Wed Nov 11 16:19:56 UTC 2015

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

More information about the OWASP-Leaders mailing list