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 1. http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/ 2. http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/#option_1_wipe_the_page_clean On 15 Jan 2014, at 7:30 am, Tommy Williams <to...@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" <cmarc...@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 <cmarc...@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 <agri...@chromium.org> wrote: > > > >> Actually, looking again, there's a custom API just for SSL certs that > >> will provide you the cert to check: onReceivedSslError(). > > >
