[guardian-dev] NetCipher: StrongTrustManager status?
Mark Murphy
mmurphy at commonsware.com
Mon Apr 7 12:54:54 EDT 2014
On Sun, Mar 23, 2014, at 19:29, Nathan of Guardian wrote:
> Our plan is the NetCipher is the one library that pulls together all the
> tricks, and makes it easy to use them. We still need to integrate
> Pinning and MemTrust, but once we do that and clean up the samples
> (maybe add one for OkHTTP), I think it will achieve what we want.
OK. I am not quite certain how this squares with your statement that
StrongTrustManager will be put to pasture, but I'm assuming that you
have a plan here. :-)
As another take on the problem space, I cobbled together a
TrustManagerBuilder and put it in my CWAC-Security library:
https://github.com/commonsguy/cwac-security/blob/master/TrustManagerBuilder.markdown
It offers a fluent builder-style interface to try to make it easier to
handle basic SSL problems, like self-signed certs. I also have my own
implementation of the certificate memorization pattern, as I have qualms
about ge0rg's implementation from an Android standpoint.
TrustManagerBuilder is purely a construction API, blending other
TrustManager implementations together using a CompositeTrustManager for
handling chaining and light boolean logic. You wind up with stuff like:
new TrustManagerBuilder(this)
.useDefault()
.or()
.selfSigned(R.raw.selfsigned, "foobar".toCharArray())
.and()
.memorize(options)
.buildArray()
to get a TrustManager[] for use with an SSLContext or whatever. In this
example, we will accept any SSL certificate that is recognized by the
default keystore or matches a self-signed certificate, and also is one
that we have memorized previously.
All I am doing is trying to stitch together existing SSL recipes into a
convenient-yet-flexible API. Those recipes that I am using may well have
flaws, and I am up for any and all suggestions on how to improve this
stuff. I also have no problems deprecating this in favor of NetCipher at
some point in the future.
I really didn't want to step on your guys' toes here, but I just can't
talk about security and assume that Android developers are going to be
able to find and grok disparate SSL recipes... and, right now, NetCipher
is not any easier to grok, unfortunately. We have too many developers
taking the Fandango/Credit Karma "accept-all" TrustManager route, and I
wanted to start fixing that problem, even if my solution winds up being
left by the wayside by an improved NetCipher in the fullness of time.
On Mon, May 24, 2014, Hans-Christoph Steiner wrote:
> You can try our progress on figuring out how this should all fit together here:
> https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification
>
> Feedback, comments, flames, etc. welcome
Near as I can tell, it's great. The problem is that I'm more facile with
SSL than is your average Android developer, and I can only grok about
80% of it. Admittedly, this page seems to be aimed at Guardian Project
developers, more so than rank-and-file Android developers, and I'm
somewhere in between with respect to skills in this area. That being
said, it was useful in concert with other stuff I read to get a better
handle on this -- thanks!
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy
_The Busy Coder's Guide to Android Development_: Version 5.7... Updated
in March 2014!
More information about the Guardian-dev
mailing list