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

Hans-Christoph Steiner hans at guardianproject.info
Mon Mar 21 10:27:24 EDT 2016



Mark Murphy:
> On Mon, Mar 21, 2016, at 09:39, Hans-Christoph Steiner wrote:
>> As for a plan for integrating this into NetCipher, I'd like to start
>> with the HttpURLConnection first, especially the SNI stuff.  
> 
> Does "the HttpURLConnection" mean you want the StrongConnectionBuilder?
> Or are you referring to something else?
> 
>> As for OrbotInitializier, ideally that would be merged into OrbotHelper
>> somehow.  
> 
> I am not aware of any conflicts there. IIRC, OrbotHelper is a basket of
> static methods.
> 
>> I see you made a StatusCallback interface.  Is there any need
>> to have separate Orbot status handling for each HTTP API?
> 
> There isn't separate handling for each API.
> 
> In my book sample code, the netcipher-hurl module serves double-duty as
> the home for HttpURLConnection support and as a "common" module for
> things like OrbotInitializer that are needed for all APIs. I didn't
> anticipate a need for a "common" module when I started out, then ran
> into deadline issues and elected to not try to separate that out. I
> apologize for any confusion there.
> 
> For formal integration into NetCipher, the following classes from
> netcipher-hurl ideally should go into libnetcipher:
> 
> - OrbotInitializer
> - StatusCallback
> - StrongBuilder
> - StrongBuilderBase

Can you explain the rationale behind using the StrongBuilderBase?


> as those are common to all four of the HTTP API integrations. The
> remaining classes are specific to HttpURLConnection and could go in
> libnetcipher or a separate artifact/module. The other three integrations
> really need to go into separate artifact/modules, simply because they
> depend upon third-party libraries (e.g., Volley), and you don't want to
> force all NetCipher users to pull in all those dependencies.

Yeah, we'll need to also do this for the existing ch.boye code there as
well. I'm thinking that the maven artifacts should be called:

netcipher  (the common one with the HttpsURLConnection stuff too)
netcipher-chboye
netcipher-httpclient
netcipher-okhttp3
netcipher-volley

I imagine will want to entirely ditch the ant/eclipse stuff in
netcipher.git at this point, and switch it all to gradle and Android
Studio.  I stuck with eclipse so far because it seemed really painful to
get the JUnit test suite working with gradle+Android Studio.

Also, I think we want to de-emphasis the custom keystore stuff.  Maybe
we should not even include it in the new APIs, just leave it as is in
the ch.boye stuff.  Perhaps it could end up being an easy approach to
doing a form of pinning: only include the CAs that your app actually
uses.  But I worry about the lack of tests and the maintenance.


> BTW, and FWIW, the sample code is now in my book's GitHub repo:
> 
> https://github.com/commonsguy/cw-omnibus/tree/master/Internet/HTTPStacks

Excellent :)

.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