[guardian-dev] Using tlspretense to test NetCipher's TLS verification

Abel Luck abel at guardianproject.info
Sun Jun 2 18:43:18 EDT 2013


Nathan of Guardian:
> On 05/31/2013 10:35 PM, Lee Azzarello wrote:
>> This is a cool project! What is it actually testing and why would this
>> effect different applications differently? Isn't openssl the only
>> library used for verifying TLS certificates in all our apps?
> 
> Android contains different versions of OpenSSL with different bugs in
> it. Since it is part of /system libs, the version of OpenSSL included in
> a particular version of Android is never updated, unless the system is
> patched. When we compile Tor, this has lead us to package our own
> version of libcrypto, etc, within Tor, so we do not rely upon the built
> in libraries.
> 

To clarify (because the working got me at first): different versions of
Android contain different versions of OpenSSL. I've yet to see one
Android version with multiple OpenSSLs (in /system).

> Anyhow, separate from all of this is the fact that at the Java layer,
> you can supply your own TrustManagers to implement your own
> certification (client, server, chain, etc) verification. This is how
> Ge0rg's MemorizingTrustManager (TOFU-POP) works, and how Moxie's
> LibPinning works.
> 
> One of the features of NetCipher (aka OnionKit) is that it includes
> StrongTrustManager, which is our own implementation of certification
> verification. The motivation was that:
> 
> 1) We wanted to be able to control our own set of trusted root CA Certs,
> and make it easy for developers to use ours (based on Debian/Mozilla's set)
> 

What is wrong with the builtin certs you might ask? Well, in AOSP,
nothing really. But manufactures and distributors can change that cert
bundle.

It's not out of the question for a government to force a carrier in a
country to install their own CA cert.

> 2) We wanted to be able to include more user interaction in the cert
> approval process, so we could show browser like SSL cert
> icons/notifications, instead of just a binary approve/deny.
> 
> 3) We wanted to have a consistent TrustManager implementation no matter
> the phone, OS, manufacturer, country, etc... ultimately, we felt this
> was a piece we needed to know we could trust.
> 
Again, we want to be able to defend against Android versions that have
been backdoored with custom CA certs or broken/backdoored TLS
implementations. Though I do think an adversary backdooring a TLS
verification implementation is unlikely.

> Moxie thinks it is a bad idea for us to do this, because, and I agree,
> writing and maintaining a TrustManager is very very hard. I have already
> made a few mistakes in our implementation, and obviously, based on the
> current tests from Abel's efforts, we have a few more holes to fill.
> However, I think the pain, effort and short-term face slapping is worth
> it, if we can come up with a trusted solution here, that works better
> than what is in by default.
> 
> Otherwise, for MOST apps, all you really need is Moxie's LibPinning,
> since most apps only connect to one server, and you can usually just pin
> that one server. It is only with general purpose communication apps,
> like chat apps and browser, where we the need to handle this broader
> issue of cert validation.
> 

Indeed, we should make this more clear in our documentation.

> I am really excited about having this TLSPretense test suite up now, and
> think we can work through the failed cases in the next few days.
> 

It's not running 24/7. Lets chat on IRC and figure out a way to best get
it running so you can test with it too!

~abel

> +n
> 
> _______________________________________________
> 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/abel%40guardianproject.info
> 
> You are subscribed as: abel at guardianproject.info
> 



More information about the Guardian-dev mailing list