[guardian-dev] NetCipher Book Chapter, and HTTP Stack Integration

Hans-Christoph Steiner hans at guardianproject.info
Thu Feb 25 08:01:40 EST 2016



Mark Murphy:
> I have written a chapter for _The Busy Coder's Guide to Android
> Development_ on the use of NetCipher. Along the way, I wrote integration
> code to tie NetCipher into:
> 
> - OkHttp3 (including using it with Retrofit)
> - HttpURLConnection
> - Apache's independent packaging of HttpClient
> - Volley
> 
> Here is the draft chapter, in PDF form:
> 
> https://commonsware.com/misc/NetCipher.pdf
> 
> One section is missing towards the end (you'll see a "TBD" there), but
> it is otherwise complete. Forgive the sidebars, but since this is a new
> chapter, it gets those on the first book update containing the chapter.
> 
> Here is a ZIP file containing the sample project and HTTP integration
> code:
> 
> https://commonsware.com/misc/HTTPStacks.zip

Any chance of viewing this in git?


> When I ship the book update containing this chapter in the second half
> of March, I'll release a copy of this chapter under a Creative Commons
> license. Also, the HTTP integration code is all Apache License 2.0; you
> are welcome to any of that if you want it.
> 
> I welcome any feedback on the prose or the code!

I'll start digging into these.  I looked at netcipher-hurl, that seems
to be a simplified duplication of what's already in the
NetCipher.getHttpURLConnection() methods, based on the
TlsOnlySocketFactory.java class.  Was that deliberate?


> I do not believe that setPackage() is sufficient, for the Orbot status Intent, to get Orbot to run after a fresh installation, if the user has not run the Orbot activity. As of Android 3.1, apps are installed in a so-called “stopped state”, where manifest-registered receivers will not receive broadcasts of implict Intents. Using an explicit Intent, as I am, will help here.

Ok, that's interesting.  I couldn't find where you are making an
explicit Intent for this.


> While NetCipher works fine if Orbot is running, the Orbot auto-start based on that broadcast
> did not seem to work all that well, particularly on older/slower hardware. It may be that my
> 30-second timeout before assuming that we’ll never hear back from Orbot is too short.

It could easily take Orbot more than 30 seconds to complete the whole
Tor startup sequence.  That's a key reason for the Intent broadcasts
with the OFF/STARTING/ON/STOPPING status.  That let's the app then
respond accordingly, like holding network connections when in the
STARTING state.


> The OrbotInitializer class that implements the callback mechanism, the signature checking,
> and so on, could in theory be merged into OrbotHelper. I specifically wanted to avoid
> changing anything in libnetcipher itself, which is why I broke it out into a separate class.

The end goal is to have this stuff all nicely integrated into its most
natural homes: either the netcipher library or the upstream HTTP libraries.


> • I had tons of trouble trying to use the Debian keystore you have as a raw resource. The
> build tools do not seem to want to let me reference that via an R.raw identifier. To work
> around that, I made a copy of that keystore in assets/, which is more flexible. All else being
> equal, I'd recommend that NetCipher go the assets/ route, but it may be possible that the
> R.raw problem can be overcome once some of this code gets merged directly into
> libnetcipher.

I think we should skip that approach entirely, and leave only where it
was used for backwards compatibility.  AndroidPinning provides a more
manageable approach to certificate pinning.  If you are interested in
looking more into that, it could be a new chunk of work related to this.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556


More information about the guardian-dev mailing list