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

Hans-Christoph Steiner 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.

.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
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556


More information about the guardian-dev mailing list