Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of cmarcelk@gmail.com designates
 209.85.213.52 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Adding SSL Certificate Pinning to Cordova
From: Marcel Kinard <cmarcelk@gmail.com>
In-Reply-To: <466D534D-C4C2-4242-8E15-ECC08F3DFD2B@gmail.com>
Date: Tue, 14 Jan 2014 11:40:45 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <FCB58BD9-E81D-4F8A-ADEA-27A515179CAB@gmail.com>
References: <A65B7E34-307D-4D70-A6F1-23B64AC9F308@devgeeks.org>
 <CADVgkyMWmEg+6BgD7L3vpwtobeO8fNOt56C7GV9-Bc1zrPMe6Q@mail.gmail.com>
 <CABiQX1WrUM3J8FHTdQH6ohMAB_bPkWeYYpBHtk-U5O7a4GPnGA@mail.gmail.com>
 <CEAC1C59-574F-4422-984E-702BA264C96C@devgeeks.org>
 <B1CFDB90-D851-46BF-AD37-C2553F19F4FC@gmail.com>
 <4C3AE595-7B77-4240-A364-2D1D8C3F4487@devgeeks.org>
 <CAOBL_k7E1Wj27QAc7AaH-otQsjtFG6+1oppo0wmqsXXaEhfPrw@mail.gmail.com>
 <CABiQX1XyUqYqfLwR7tksYhNcG+sj-28CJ0zWwCwqUFPj3OFLiQ@mail.gmail.com>
 <B82C9A4A-4AA7-44DD-A87E-52BED742A927@devgeeks.org>
 <CABiQX1UbYcx3LmHk1H9HZyTiEOJ6Y+yiSS6SLc4vN6tS8rOvFg@mail.gmail.com>
 <466D534D-C4C2-4242-8E15-ECC08F3DFD2B@gmail.com>
To: dev@cordova.apache.org

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.=20=

>=20
> 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).
>=20
> When setting the app to debuggable=3Dtrue 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.
>=20
> When using debuggable=3Dfalse, 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.
>=20
> On Jan 14, 2014, at 10:42 AM, Andrew Grieve <agrieve@chromium.org> =
wrote:
>=20
>> Actually, looking again, there's a custom API just for SSL certs that
>> will provide you the cert to check: onReceivedSslError().
>=20