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

Rogan Dawes rogan at dawes.za.net
Thu Nov 5 12:47:10 UTC 2015


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20151105/62b564f1/attachment.html>


More information about the OWASP-Leaders mailing list