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

Matt Konda matt.konda at owasp.org
Thu Nov 5 17:34:31 UTC 2015


Can someone update the WIKI page with the detail and nuance here because I
think it improves the content substantially.

Thanks!
Matt


On Thu, Nov 5, 2015 at 10:01 AM, Tim <tim.morgan at owasp.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20151105/0cf92aa2/attachment-0001.html>


More information about the OWASP-Leaders mailing list