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

Gary Robinson gary.robinson at owasp.org
Wed Nov 11 20:56:22 UTC 2015


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> 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
> 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
>
>
> _______________________________________________
> 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/f04f6733/attachment-0001.html>


More information about the OWASP-Leaders mailing list