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 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
