[guardian-dev] NetCipher: StrongTrustManager status?

[Hans-Christoph Steiner]

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

FYI, it looks like Debian is moving to directly using Mozilla's CA collection,
and dropping CACert.org.  They apparently have not had a good audit and some
public results are not encouraging.  Hard to say if cacert.org is worse than
your average commercial CA though.


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

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

.hc



>> - 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... :-)
>>
> 
> _______________________________________________
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info
> 
> You are subscribed as: hans at guardianproject.info
> 

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81