[guardian-dev] NetCipher: Integrate Tor Status Check?
hans at guardianproject.info
Fri May 13 02:40:43 EDT 2016
I'm pretty sure that https://check.torproject.org/api/ip is meant to be
around for good.
I like the idea of enforcing by default, but I worry about unintended
consequences of checking https://check.torproject.org/api/ip before
setting up an instance. Perhaps it is something like the check whether
Orbot is installed: run only on the first time NetCipher is used to get
an HTTP stack instance.
Also, for what its worth, .onion addresses would not need any
https://check.torproject.org/api/ip checks since they only work through Tor.
> When I wrote my book sample app demonstrating integrating NetCipher with
> popular HTTP stacks, I added code to check
> https://check.torproject.org/api/ip to see whether our HTTP connection
> is really routed over Tor. Basically, I get the JSON back and confirm
> that the JSON says we did that request over Tor.
> However, I left that code in the app, rather than pushing that down into
> the library. Now that I am converting this book sample into actual
> NetCipher code, I would like to know what interest there is in this
> validate-that-we're-really-on-Tor capability.
> We could:
> 1. Always validate that https://check.torproject.org/api/ip says that we
> are on Tor, and not hand back an HTTP client object (e.g.,
> HttpURLConnection) if we are not on Tor, for a stronger security
> 2. Same as #1, with an opt-out option, skipping the status check in that
> 3. Offer an opt-in validation, so the developer has to call
> validateTorStatus() on their StrongBuilder to have us check the status
> 4. Always hand back the HTTP client object without checking the Tor
> status, but provide some other utility method on the builders to check
> the status given that client object, that developers could call if they
> wanted (putting this on the builders as the logic to check the
> connection is tied to the particular HTTP stack that we're using)
> 5. Have this code as part of a test suite for demonstration purposes but
> not have it be part of the library proper
> 6. Ignore this entirely (#YOLO)
> My gut instinct is #4, as I don't know whether
> https://check.torproject.org/api/ip is considered mission-critical
> infrastructure for Tor. If we're sure that
> https://check.torproject.org/api/ip should always be around (and should
> be afraid if it is not), then I'd be more inclined to go with one of the
> earlier options.
PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556
More information about the guardian-dev