[guardian-dev] NetCipher: Integrate Tor Status Check?

Hans-Christoph Steiner hans at guardianproject.info
Fri May 13 02:42:02 EDT 2016

Really, I should say, connecting to a .onion instance would provide the
same assurance as https://check.torproject.org/api/ip, so if that's the
URL, and it successfully connects, connecting to the .onion would count
the same as verifying via https://check.torproject.org/api/ip


Hans-Christoph Steiner:
> 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.
> .hc
> Mark Murphy:
>> 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
>> statement
>> 2. Same as #1, with an opt-out option, skipping the status check in that
>> case
>> 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.
>> Thoughts?
>> Thanks!

PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556

More information about the guardian-dev mailing list