[guardian-dev] NetCipher: StrongTrustManager status?

Nathan of Guardian nathan at guardianproject.info
Sun Mar 23 22:29:16 EDT 2014


Oops... continued inline

On 03/23/2014 10:25 PM, Nathan of Guardian wrote:
> 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:

  OkHttpClient okHttpClient = new OkHttpClient();
      SSLContext sslContext;
      try {
        sslContext = SSLContext.getInstance("TLS");
        sslContext.init(null, null, null);
      } catch (GeneralSecurityException e) {
        throw new AssertionError(); // The system has no TLS. Just give up.
      }
      okHttpClient.setSslSocketFactory(sslContext.getSocketFactory());

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

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.

For now, at least, we've fixed some bugs and addressed new worries about
ciphers, etc. Abel, Hans and I are meant to be putting some more cycles
into in the next few months, and we will start by communicating our
roadmap plan a bit better.

>> Of course, even better would be to get rid of the android:configChanges
>> requirement in the first place... :-)

Yes, will look into that!

+n



More information about the Guardian-dev mailing list