cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Kinard <cmarc...@gmail.com>
Subject Re: Adding SSL Certificate Pinning to Cordova
Date Tue, 14 Jan 2014 16:40:45 GMT
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
View raw message