[guardian-dev] NetCipher interface for anonymity configurations

[Hans-Christoph Steiner]

Mark Murphy:
> On Sun, Nov 13, 2016, at 04:22, Hans-Christoph Steiner wrote:
>> For example:
>>
>> * TLS Session Identifiers/Tickets
> 
> I have limited experience in this area and so cannot comment
> authoritatively. My gut tells me that it'll be impractical for NetCipher
> to affect, as app developers have very little visibility into the SSL
> communications processing, and even less on Android 7.0+ (as
> Conscrypt/network security configuration takes over that work).

There is an API for doing this, let's hope Android continues to respect
it.  I'm going to test this with wireshark hopefully this week:
https://github.com/eighthave/NetCipher/commits/f1e709dfe128bf35d7e73c796354559ba8323592

 SSLCertificateSocketFactory factory = (SSLCertificateSocketFactory)
delegate;
 factory.setUseSessionTickets(socket, false);


>> * detailed info in HTTP User Agent
>> * HTTP ETag
> 
> With HTTP headers, usually, last one in wins. That's a problem, as
> NetCipher is not the one executing the HTTP request. The app is.
> NetCipher sets up an HTTP client API object (e.g., an HttpURLConnection,
> an OkHttpClient) with some stuff pre-configured. NetCipher then hands
> that over to the app, which makes the call. If NetCipher sets the
> header, and the app sets the header, the app's header will win. And, by
> "the app", I really mean, "the app's own code plus the code of any other
> libraries that the developer is using that might be working with the
> HTTP client object" (e.g., libraries like Retrofit or Picasso, that use
> an OkHttpClient).
> 
> Now, if you're willing to say, "NetCipher will do the right thing, and
> if the developer overrides it, that's the developer's problem", that's
> doable.

Yes, that's exactly what I'm thinking. We should let the dev override
anything, but provide the best possible config by default.


>> But since some of these things provide substantial speed
>> improvements, we need to provide a way to disable them.
> 
> That would mostly be a matter of adding disable methods to the
> StrongBuilder classes, and using that info when configuring the HTTP
> client API objects.
>
>> One idea would be to tell devs to use plain networking when going direct
>> and not through Tor.  
> 
> What is "plain networking" in this context?

Not modified by NetCipher, e.g. without a StrongBuilder.


>> Another would be to have methods to disable
>> specific settings. I'm hoping to open up the discussion to hear other
>> ideas.
> 
> While the StrongBuilder system right now assumes that the point is to
> try to run through Tor, it could be change that Tor itself is an
> optional thing. In that case, the StrongBuilders would configure this
> other stuff and skip setting up the Tor proxy hooks.

Sounds good.

.hc

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