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

Jim Manico jim.manico at owasp.org
Wed Nov 11 21:46:44 UTC 2015


Awesome. I'll get Mr. Walton (the original author) to help review once 
the next version is done.

There has been tons of cheatsheet activity lately, I'm stoked. Thanks 
everyone for jumping in to help.

Aloha,
Jim


On 11/11/15 3:56 PM, Gary Robinson wrote:
> Hi Jim,
>
> Yea I'm going to take a stab at updating those pages soon, based on 
> this discussion.
>
> Gary
>
> On Wed, Nov 11, 2015 at 8:41 PM, Jim Manico <jim.manico at owasp.org 
> <mailto:jim.manico at owasp.org>> wrote:
>
>     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 <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
>     <mailto: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
>>>>     <mailto: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 <mailto: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
>>>>>>     <mailto:OWASP-Leaders at lists.owasp.org>
>>>>>>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>>>
>>>>>>
>>>>>     _______________________________________________
>>>>>     OWASP-Leaders mailing list
>>>>>     OWASP-Leaders at lists.owasp.org
>>>>>     <mailto:OWASP-Leaders at lists.owasp.org>
>>>>>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>>
>>>>     _______________________________________________
>>>>     OWASP-Leaders mailing list
>>>>     OWASP-Leaders at lists.owasp.org
>>>>     <mailto:OWASP-Leaders at lists.owasp.org>
>>>>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>     _______________________________________________
>>>     OWASP-Leaders mailing list
>>>     OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org>
>>>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>     _______________________________________________
>>     OWASP-Leaders mailing list
>>     OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org>
>>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>     _______________________________________________
>     OWASP-Leaders mailing list
>     OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org>
>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>

-- 
Jim Manico
Global Board Member
OWASP Foundation
https://www.owasp.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20151111/c1576e29/attachment-0001.html>


More information about the OWASP-Leaders mailing list