[guardian-dev] NetCipher: StrongTrustManager status?

[Nathan of Guardian]

On 03/21/2014 07:15 PM, Mark Murphy wrote:
> Hi! What's the status of NetCipher? I see that there was a 1.1 tag
> applied a few days ago.

Yes, a few bugs have been fixed, and a few improvements made, thanks
mostly to submitted patches, community feedback:

- Fixed DNS leaking on SOCKS proxy connections
- Best ciphers suites and TLS version support as specified for SSL Sockets
- fixed code to enable WebView proxying, to work with latest KitKat/4.4

> - What is the status of StrongTrustManager? The README indicates that it
> was removed, but the code is still there.

It is still there, but not linked in by default to anything. I should
probably just remove it, and here is why... with the #GOTOFAIL incident
once again showing us how hard certificate verification is, I have
decided it is not something we should tackle, and for better or worse,
we should use what Android provides us.

Also, there are other ways to improve the verification process
indirectly, which solve the problem for most people:

1) Use a custom, better RootCA store (we use our own built-in Debian
Root CA based, built into NetCipher), to avoid per device additions of
operator, manufacturer, gov't RootCA's

2) Use pinning for the specific servers your app needs (via
AndroidPinning lib)

3) Use trust-on-first-use model to support user override of untrusted
sites (via MemorizingTrustManager)

> - The README indicates that StrongTrustManager works with
> MemorizingTrustManager, by which I assume you mean
> https://github.com/ge0rg/MemorizingTrustManager. Any notes on how best
> to combine these?

You can chain TrustManager's and MemorizingTrustManager specifically has
a way to wrap your own TrustManager.

> - The 1.1 release just contains the source tarball/zipball. Are you
> planning on releasing this as an AAR? I'm assuming that a JAR is out of
> the question, since the library contains resources.

Right now we just have the project, that should be added as an external
submodule. We are slowly moving to AAR's.

> - I notice that the sample only uses StrongHttpsClient. I was planning
> on using StrongSSLSocketFactory with OkHttp, since HttpClient is no
> longer recommended on Android. Are there any notes anywhere about how
> best to set up StrongSSLSocketFactory?

That's a great idea... we do not have any samples yet on using
StrongSSLSocketFactory on its own, but if you look at the
StrongHTTPSClient, it is pretty easy to init:

https://github.com/guardianproject/NetCipher/blob/master/libnetcipher/src/info/guardianproject/onionkit/trust/StrongHttpsClient.java#L40

and here is what seems to be OkHTTP code:


> I ask, because it's high time for me to start adding complex SSL samples
> to my book, and I'm trying to determine to what extent I should be
> pointing people at StrongTrustManager to help with any of that. Plus, I
> have a security presentation in London in a little bit, and I'm trying
> to determine how to position NetCipher in that talk.
> 
> Thanks!
> 
> --------------------
> 
> Also, one technical comment on the README: towards the bottom, it has
> "If you are targetting android-13 as the minimum...". That probably
> should be "If your build target is API Level 13 or higher", as the
> screenSize value for android:orientation only requires that you be
> compiling against a high enough build target. android:minSdkVersion does
> not matter, nor does android:targetSdkVersion, and the verb "targetting"
> is a bit vague as a result.
> 
> Of course, even better would be to get rid of the android:configChanges
> requirement in the first place... :-)
>