Re: [guardian-dev] NetCipher Book Chapter, and HTTP Stack Integration
Mark Murphy: > On Mon, Mar 28, 2016, at 07:42, Hans-Christoph Steiner wrote: >>> To help prevent memory leaks, in case clients fail to unregister their >>> callbacks. >> >> I'd prefer to error/warn the user about this rather than reducing the >> impact of doing the wrong thing. I vaguely remember seeing such >> warnings in logcat. > > You have *far* greater faith in software developers than I do. I think I might have less, since I'd like to make it a hard fail error to force people to do the right thing :) >> I'm saying remove the keystore references from your code entirely, for >> now at least. > > OK, will do. With luck, I will submit pull requests later this week. Looking forward to it. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556 ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] NetCipher Book Chapter, and HTTP Stack Integration
Mark Murphy: > On Fri, Mar 25, 2016, at 05:36, Hans-Christoph Steiner wrote: >> * why did you use the custom WeakSet class rather than just a plain Set? > > To help prevent memory leaks, in case clients fail to unregister their > callbacks. I'd prefer to error/warn the user about this rather than reducing the impact of doing the wrong thing. I vaguely remember seeing such warnings in logcat. >> * keep things as a JAR as much as possible, not an AAR, i.e. by avoiding >> string resources, etc. I find it makes the library a lot easier to >> deploy in a variety of situations (ant!). > > What do you want to do about the keystore? > > In my sample, I moved that to an asset, as I was having problems > referencing the raw resource across library module boundaries. However, > if you're aiming to change packaging to be a JAR instead of your current > AAR, then the keystore cannot be either a raw resource or an asset. > > Options include: > > - Remove the keystore references from my code entirely, with an eye > towards revamping all this (e.g., your proposed "make it look like > Android N" approach). > > - Leave the keystore references more or less as-is, and tell users of > the library that they need to put the keystore in the proper spot in > assets/ (i.e., the old SQLCipher approach, before they switched to the > AAR). > > - Add something (to OrbotHelper?) that exposes the keystore from raw > resources via a Java API, then have my code use that API, and leave the > raw resource where it is, requiring AAR packaging. > > - Attempt to switch this to an old-style Java JAR resource (note: not > recommended, as I worry that the Android tools team will eventually > break that). > > And there may be other options that I'm not thinking of, as I just woke > up. I'm saying remove the keystore references from your code entirely, for now at least. I think that approach could be good, but I'd like to have it wrapped in a proper test suite before deploying it any more. Right now, the focus of this round of work is improved proxy/tor integration. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556 ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] NetCipher Book Chapter, and HTTP Stack Integration
On Mon, Mar 28, 2016, at 07:42, Hans-Christoph Steiner wrote: > > To help prevent memory leaks, in case clients fail to unregister their > > callbacks. > > I'd prefer to error/warn the user about this rather than reducing the > impact of doing the wrong thing. I vaguely remember seeing such > warnings in logcat. You have *far* greater faith in software developers than I do. > I'm saying remove the keystore references from your code entirely, for > now at least. OK, will do. With luck, I will submit pull requests later this week. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] netcipher integrated pinning idea
On Mon, Mar 28, 2016, at 13:42, Hans-Christoph Steiner wrote: > So NetCipher's ch.boye for a long time has included the ability to use a > custom keystore. Mark and I have been thinking that this could be a > good approach for a form of integrated pinning in the NetCipher wrappers > for all of the various HTTP APIs (HttpURLConnection, Apache HttpClient > for Android, Volley, OkHTTP, etc). The core idea would be a gradle > plugin or script that downloads the Mozilla CA certificates collection, > then fines the CA used by a provided HTTPS connection, then builds a > custom keystore that only includes that specific CA's certificate from > the Mozilla collection (turns out that Android N is including something > very similar). To clarify: what Android N offers is custom CA validation and certificate pinning, baked into the framework. It does not have the automatic generation of the credentials, leaving that up to you. Also, it does not use keystores, but rather PEM or DER files. See: http://developer.android.com/preview/features/security-config.html So, there are two pieces to your proposed puzzle: 1. A Gradle plugin that generates the PEM/DER file(s) (at minimum) necessary to lock an app down to only support certain CAs, based on the root CA of the certificate chain for an HTTPS connection 2. A quasi-backport of the Android N network security configuration stuff, presumably to integrate with NetCipher, where we apply the same security configuration on Android 6.0 and older devices Those are more-or-less independent: the plugin could be used for an app with a minSdkVersion of N, and the backport could be used without the plugin (e.g., for certificate pinning). Both seem to have merit, though I think the latter one is more important, if we can pull it off. Backwards compatibility is A Very Good Thing for adoption, and while Google might offer their own backport of this stuff, my guess is that they will not. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
[guardian-dev] netcipher integrated pinning idea
So NetCipher's ch.boye for a long time has included the ability to use a custom keystore. Mark and I have been thinking that this could be a good approach for a form of integrated pinning in the NetCipher wrappers for all of the various HTTP APIs (HttpURLConnection, Apache HttpClient for Android, Volley, OkHTTP, etc). The core idea would be a gradle plugin or script that downloads the Mozilla CA certificates collection, then fines the CA used by a provided HTTPS connection, then builds a custom keystore that only includes that specific CA's certificate from the Mozilla collection (turns out that Android N is including something very similar). I'd love to hear feedback, flames, comments, etc on whether this would be a good idea both in terms of security and easy of use. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556 ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
