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

Mark Murphy mmurphy at commonsware.com
Thu Feb 25 08:19:54 EST 2016


On Thu, Feb 25, 2016, at 08:01, Hans-Christoph Steiner wrote:
> Any chance of viewing this in git?

Not until it gets released. At that point, it will be in my book's
massive repo (https://github.com/commonsguy/cw-omnibus), along with the
rest of my book samples.

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

No.

My biggest problem with all of this is that NetCipher is undocumented
AFAICT. Hence, I worked off of the sample app to determine what is and
is not your supported API. I didn't notice a getHttpURLConnection()
method. I'll run a comparison and make changes if needed -- thanks!

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

That's inside validateBroadcastIntent(), over in my CWAC-Security
library. For the purposes of my book, having it there is fine. For any
long-term NetCipher reuse, we'd want to copy the logic from there or do
something equivalent, so there's no dependency on something tiny like
this:

https://github.com/commonsguy/cwac-security/blob/master/security/src/main/java/com/commonsware/cwac/security/SignatureUtils.java#L70-L152

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

StatusCallback could be expanded for the other states. Again, it's not
obvious what is and is not part of the supported API.

Expanding StatusCallback is out of scope for the current book sample
(like your sample, it doesn't really need it), but it's clearly
something that could be added as part of any long-term NetCipher reuse.

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

If you mean https://github.com/moxie0/AndroidPinning, that's GPLv3.

Thanks!

-- 
Mark Murphy (a Commons Guy)
https://commonsware.com | https://github.com/commonsguy
https://commonsware.com/blog | https://twitter.com/commonsguy


More information about the guardian-dev mailing list