cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy-Carlos Williams <>
Subject Re: Adding SSL Certificate Pinning to Cordova
Date Thu, 23 Jan 2014 01:08:18 GMT
I am reconsidering the “deal breaker” status of only working with self-signed certs.

In one of the articles I have been using as a reference[1], Moxie Marlinspike actually prefers
the option of doing away with the CAs entirely for mobile apps and doing exactly that[2].

I can certainly think of a way that it would work better for our use case. The only use case
harmed would be wanting to pin the certs of third party services like Parse, etc.

I guess it comes down to… is it better to do something for some people than nothing for
anyone. If it could be done in a way that only impacted those that opted in, surely the former
beats the latter.

- tommy


On 15 Jan 2014, at 7:30 am, Tommy Williams <> 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" <> 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 <> 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>
> >
> > 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 <> wrote:
> >
> >> Actually, looking again, there's a custom API just for SSL certs that
> >> will provide you the cert to check: onReceivedSslError().
> >

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