cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Adding SSL Certificate Pinning to Cordova
Date Tue, 14 Jan 2014 20:41:04 GMT
added to the f2f agenda


On Tue, Jan 14, 2014 at 12:30 PM, Tommy Williams <tommy@devgeeks.org> wrote:

> Yeah, only working with self-signed certs is kind of a deal breaker.
>
> Most apps consume an api/server that is also consumed by webapps.
>
> Thanks for still thinking about this...
> On 15/01/2014 3:41 am, "Marcel Kinard" <cmarcelk@gmail.com> wrote:
>
> > And onReceivedSslError would cover the self-signed scenario, but it
> > wouldn't cover the real pinning scenario with a properly signed cert,
> > because it gets invoked only on a handshake failure, not a handshake
> > success.
> >
> > On Jan 14, 2014, at 11:38 AM, Marcel Kinard <cmarcelk@gmail.com> wrote:
> >
> > > I've played with that recently, and it may do most of what you want.
> > >
> > > The method CordovaWebViewClient.onReceivedSslError does get called when
> > attempting an SSL handshake with a server that has a self-signed cert. I
> > tested this using <a href> and window.open(_self).
> > >
> > > When setting the app to debuggable=true in AndroidManifest.xml, the
> > onReceivedSslError() method will treat this as a special case, and
> > basically ignore the SSL error by always calling
> SslErrorHandler.proceed().
> > Once proceed() has been called, subsequent SSL connections to that server
> > will not result in onReceivedSslError() getting called - once that
> > self-signed cert has been accepted, subsequent requests are considered
> > accepted also. This "acceptance" is persistent only for the duration of a
> > single application execution - if the application is restarted, it
> forgets
> > the acceptance. According to the docs, WebView.clearSslPreferences()
> might
> > reset that.
> > >
> > > When using debuggable=false, it takes a different path in
> > onReceivedSslError() and it doesn't eat the error, and the connection
> > fails. I think at this point what you'd want to do is inspect the cert to
> > see if it matches what you want, and then call proceed() if it is good.
> > However, I think the last sticking point (from what I see in the
> javadocs)
> > is that although you are handed an SslCertificate object in
> > onReceivedSslError, the methods on SslCertificate will get you only the
> > human-readable info (self DN, issuer DN, valid date) and not the actual
> > public key. So all you can check is the DN, which I don't think is good
> > enough. I don't see a way to work around that by getting the raw pem or
> > similar.
> > >
> > > On Jan 14, 2014, at 10:42 AM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> > >
> > >> Actually, looking again, there's a custom API just for SSL certs that
> > >> will provide you the cert to check: onReceivedSslError().
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message