Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of tommy@devgeeks.org designates
 209.85.192.181 as permitted sender)
From: Tommy-Carlos Williams <tommy@devgeeks.org>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_50836D70-E508-4078-85D1-26DE499FCDA7"
Message-Id: <0AC46520-9B83-4934-8E4B-BCEAC44F2DFE@devgeeks.org>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: Adding SSL Certificate Pinning to Cordova
Date: Thu, 23 Jan 2014 12:08:18 +1100
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>
 <FCB58BD9-E81D-4F8A-ADEA-27A515179CAB@gmail.com>
 <CAPTyS6CkQkoSBoPVj2QgZU4zkGTataT+dAWL3crD6QvdAk=yOw@mail.gmail.com>
To: dev@cordova.apache.org
In-Reply-To: 
 <CAPTyS6CkQkoSBoPVj2QgZU4zkGTataT+dAWL3crD6QvdAk=yOw@mail.gmail.com>

--Apple-Mail=_50836D70-E508-4078-85D1-26DE499FCDA7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I am reconsidering the =93deal breaker=94 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=85 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


1. =
http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-ap=
p-ha/
2. =
http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-ap=
p-ha/#option_1_wipe_the_page_clean


On 15 Jan 2014, at 7:30 am, Tommy Williams <tommy@devgeeks.org> wrote:

> Yeah, only working with self-signed certs is kind of a deal breaker.
>=20
> Most apps consume an api/server that is also consumed by webapps.
>=20
> Thanks for still thinking about this...
>=20
> 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.
>=20
> On Jan 14, 2014, at 11:38 AM, Marcel Kinard <cmarcelk@gmail.com> =
wrote:
>=20
> > 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=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.
> >
> > 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.
> >
> > 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().
> >
>=20


--Apple-Mail=_50836D70-E508-4078-85D1-26DE499FCDA7--