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

Gary Robinson gary.robinson at owasp.org
Thu Nov 5 13:32:36 UTC 2015

Good point regarding the private key being exposed in HeartBleed, therefore
you could put multiple public keys in the client pinning code and hold
those corresponding private keys as backups.  As others state you could pin
on the intermediate cert public key, I haven't tried that before, however
the intermediate cert is not under your businesses control.  It could also
get reverted, plus I don't know if there's any guarantee the next cert you
get (after a breach) will have the same cert path.

On Thu, Nov 5, 2015 at 12:40 PM, Tudor Enache Owasp <tudor.enache at owasp.org>

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

More information about the OWASP-Leaders mailing list