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
.hc 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 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
