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

[Hans-Christoph Steiner]

Mark Murphy:
> 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!

The sample app is mostly for the ch.boye methods at this point, but
yeah, we need to improve the docs and sample app.  The HttpURLConnection
stuff is quite simple, here are some examples:

https://github.com/theScrabi/NewPipe/pull/136/files


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

This is like our "Trusted Intents" library, which reminds me that I've
been meaning to discuss your versions of this stuff. :)  FYI, ours is here:

https://github.com/guardianproject/TrustedIntents

So I guess the key bit there in terms of making the Intent start Orbot
not matter what its state is the Intent.setComponent() call?


>> 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 I'm missing something.  Orbot sends OFF/STARTING/ON/STOPPING
status now.  I don't think we need to extend the status states or change
that stuff at all.  It just needs to be clear to the app developer that
if the app is using Tor and Orbot is not in the ON state, the app will
not have working network connectivity.


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

Yeah, that's the one.  I could make sense to make NetCipher work well
with AndroidPinning, but even better would be to have a full
pinning/TOFU support built-in.  Here's the archtecture for that that
I've been working on over the years:

https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification

.hc

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