- tor-dev - lists.torproject.org

maint-0.4.2 is now a separate branch; master is now 0.4.3.x
by Nick Mathewson 11 Oct '19

11 Oct '19

Hi! If you're writing a patch that needs to go into Tor 0.4.2.x, please base it on the new "maint-0.4.2" branch. The "master" branch is now for developing the new and exciting Tor 0.4.3.x. If you use git-pull-all.sh, git-push-all.sh, or git-merge-forward.sh, please be sure to update to the latest versions in the master branch; they know about the maint-0.4.2 and release-0.4.2 branches. cheers, -- Nick

1 0

Exposing onion service errors to Tor Browser
by George Kadianakis 02 Oct '19

02 Oct '19

Hello list, we've recently been thinking about how to expose onion-service-related errors to Tor Browser so that we can give more useful error pages to users. We currently return "Unable to connect" error pages for any kind of onion service error, and I think we can do better. This is a thread to think about the errors we want to expose, how that should look like, and what options we should give to the users when it happens. Relevant master tickets are #30022, #30025 and #30000. We decided (in #14389) that Tor will export these errors through the SOCKS port, and the relevant spec is proposal 304 [0]. As part of #30090 antonela started making a table of potential errors. I'm gonna use that in this thread and also add a few more. Let's go: = Client-level errors = These are errors on the user side of things: === 1) Typo error on address === This can be detected by Tor using the checksum or if the address is too big or too small. TODO: We will need to add a new error code to prop304. Not sure if the error code should distinguish between checksum fail or length fail. There is no recovery here since the address is busted. The user needs to find the right one. === 2) Missing Client Authorization === This is prop304's 'F4' error (see #30382), and it means that we can't decrypt the descriptor because it requires client auth, but we don't have it configured. The recovery here is the whole point of #30237 where we make a dialog for the user to insert their client auth credentials. === 3) Wrong Client Authorization === This is prop304's 'F5' error, and it means that there client auth credentials configured for this onion are wrong. The user recovery here is unclear but it might be that they need to change their client auth credentials. IMO, we should not try to make the perfect UX here, and we should just go with something super simple. = Service-level errors = These are errors on the onion service side: === 4) Service Descriptor Can Not be Found === This is prop304's 'F0' error, and it means that we could not find the descriptor of the service on the directory servers. This means that the service is not up right now (or, more unlikely, that some bug has happened somewhere). The user recovery here is unclear. The user can try to reconnect in case the service got up in the meanwhile, but this is not so likely in a small period of time. Perhaps we can give the user the option to reconnect every 10 seconds or so? Does this make sense from a UX PoV? Again this equivalent to a "Remote host is down" error and we should use it as such. = Network-level errors = These are errors caused by the network (directory servers, intro points, rendezvous points) or even the service itself. It's kinda unclear given all the hops involved. === 5) Onion Service Descriptor Is Invalid === This is prop304's 'F1' error and it means that we got a descriptor back from the directory but it's corrupted. This is very unlikely to happen since directory servers do not keep corrupted descriptors, so it usually means that some bug happened somewhere (or that the directory is bad or confused). In terms of recovery and error page, this is kinda an "Oops. Internal error." situation where this is rare and weird and hence we don't know what's the best recovery option. We can give the option to reconnect but it's likely not gonna help much. Again this should never really appear, so let's not stress too much over it. === 6) Onion Service Introduction Failed === This is prop304's 'F2' error and it means that for some reason the introduction did not complete. This could be because the onion service is not up anymore, or it could be because the network is screwed in some way (e.g. the service is DoSed). The recovery here might be some 'reconnect' button which could be helpful in case of a DoS situation, but it would not help much if the service is not up anymore. === 7) Onion Service Rendezvous Failed === This is prop304's 'F3' error and it means that the rendezvous did not complete. This usually means that the service is having a bad time, and is either DoSed or it generally cannot cope. The recovery again here is some 'reconnect' button, since if we did the introduction successfuly, the service is up, and reconnecting might work at some point. This one and (6) are very related and perhaps they can be handlded identically, since exposing terms like "intro" and "rend" to users will not be nice. Still we might want to expose a technical error value somewhere for debugging purposes when users come to us. ======================================================================= I think the above set of errors will satisfy all our needs. In particular: - #30022 (typos ticket) needs error (1) from above. - #30025 (client errors ticket) needs errors (4), (5), (6), (7) from above. - #30000 (client auth) needs errors (2) and (3) from above. In terms of error page, I'm not sure how it should look like. Perhaps along with the error description and the recovery path, we should provide some education about onion services to the users? In terms of unsafe paths, I don't see any of these errors being dangerous in terms of causing security issues if you attempt to reconnect or anything. The Tor protocol takes care of this in the layer below. The worst thing you can do is slightly damage the network from too many reconnects, but I think that's OK since people who use the TB are legitimate users and not DoS attackers. === Hope this was useful! [0]: https://github.com/torproject/torspec/blob/master/proposals/304-socks5-exte…

3 3

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

Please sent me a video that how to get dark web please

3 3

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

What should I do

1 0

(no subject)
by vignesh kannan 26 Sep '19

26 Sep '19

Okay

1 0

Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography
by Jean Paul Degabriele 23 Sep '19

23 Sep '19

Hello tor-devs, Martijn Stam and myself have previously worked on analysing the security of proposal 261. Together with Martijn's PhD student, Alessandro Melloni, we have now written a proposal for an onion encryption scheme as an alternative to Proposals 261 and 295. It builds on the GCM-RUP construction from [ADL17] but it offers a number of improvements over proposal 295. In addition to addressing the issues described below we expect it to offer better performance. We are currently working on a security proof and potential efficiency optimisations for this scheme. In the meantime, we would be very happy to hear what you think and any feedback you may have. If something is unclear, please let us know. Best, Martijn, Alessandro, and Jean Paul --------------------- In our assessment of proposal 295 we identified the following issues: a) Improper use of the universal hash function. The proposal suggested using GHASH, a universal hash function, to compute the digest. Universal hash functions require their input to be independent of the hash key for security to hold. This is also a basic requirement in the tweakable block cipher construction, underlying the PIV and RUP constructions. However, the construction requires feeding back the digest (which is key-dependent) back into the input of the hash. Note that such feedback was not present in [ADL17] and the security proof breaks down with this modification. b) Lack of Forward Security for any type of hash function that is used. If instantiated with GHASH, proposal 295 does not provide forward security (as it is easy to invert given the hash key). The designers suggested (on the Tor dev mailing list) that forward security could be achieved by instantiating the hash function with SHA2 or SHAKE instead. Clearly this degrades the efficiency of the scheme but, as we argue below, it still does not suffice to achieve forward security Specifically, even if the hash function is instantiated with an ideal hash function (a random oracle), the construction succumbs to the following attack. Assume that the last OR in a circuit of length n has already processed some cells and that its current state is (Kf_n, Kb_n, Ktf_n, Ktb_n, Khf_n, Khb_n, Tf'_n, Tf'_{n+1}, Tb'_n, Tb'_{n+1}). An adversary, who has collected previous ciphertexts and nonces (C, N), then corrupts it. The adversary has enough information to recover the last message received by OR_n, which it computes as follows: N_{n+1} = Tf'_n ^ D(Ktf_n, Tf'_n ^ N_n) M = Decrypt(Kf_n, N_{n+1}, C_n). Clearly this breaks forward security, and it is enabled by the fact that the current digest needs to be saved for computing the next digest for when another ciphertext is received. [ADL17] Tomer Ashur, Orr Dunkelman, Atul Luykx, "Boosting Authenticated Encryption Robustness with Minimal Modifications", CRYPTO 2017.

3 3

Timing of opening pre-emptive circuits?
by Jeremy Rand 20 Sep '19

20 Sep '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Tor-Dev, I'm curious what the timing is of Tor's opening of preemptive circuits. Specifically, consider the following attack: 1. A new stream is assigned to a clean circuit. 2. Because of the above, that clean circuit is now a dirty circuit. 3. Because of the above, the number of clean circuits is now decreased by 1. 4. Because of the above, the number of clean circuits is now lower than the number that Tor wants to have open. 5. Because of the above, Tor opens a new preemptive circuit. 6. An attacker who can observe the circuit in (1) and the circuit in (5) can deduce by temporal proximity that those 2 circuits belong to the same client. This attack seemed obvious enough to me that I assumed that Tor must have some kind of countermeasure to it, e.g. random delays in opening preemptive circuits. However, the tor-path specification doesn't mention any such countermeasure, and based on a brief search through the Tor source code, all I can find is that Tor opens preemptive circuits using a function that always gets called once per second (with no mention of any delay beyond that one-second interval, random or otherwise). So, does Tor make any effort to mitigate the above attack? If so, what mitigations are present, and where would I find them (in both the spec and the source code)? If not, is there any documented reason (e.g. "the attack is too hard to pull off" or "we want to mitigate it but haven't gotten to it yet") for the lack of mitigation? Cheers, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile(a)airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy(a)veclabs.net is having technical issues at the moment. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEVB3fdzAraEcoBtkSs/LRZXhtZXAFAl2CoycACgkQs/LRZXht ZXDyjhAAk3F6fJUvNl4FHws6IIBHWXby/zC7MLzr9zR3sIC3RY4f/I7XBDTKKfMg iOehJlBEksm5sRz6nlybUBivsJ0WRL8VCT3rEK3+LQM7JrYNvGajolEw2apBUeB3 +Vg+Quo5JzTZrjCtXljxdps/hhC1YwEyN6pxxn2137q4XAsRPQgSCcWpsBuDTffb LFRwyGrNxk6chbpQc0GIWQRoeElxFwaLbUrZdGtaaEjBXY2oWoan1TUB34MAVNzF 1o6DlaO2JQ7weHVHoXlTlXS7gt84/WyY0xaHUY9ONHwrhgDPGv3N5+Fa2Em+PvGx ik+4iSCzPf6aKY0iUv1AsWKiaq8rRsMToyNzNZ048uYHk2IK2Zrbqh4Nm44RTzKD 84tJU71calRdNhbwuvmgsYKh26Ad9ALf9BzDeiweA3c5ZP0JP0OlLcAN9c056WT3 FQbChA1edZkWkPvBjGtl4l7ROIx6wkNpWgaQsYUCMveszB2Rm38BQw5sYLh8i6ha AlT3UVs/GJscSSsfmHGrTisao444Etp4J/+SFe1aNJwfOogbEfgJ1jRf8V5dlYEb rcicgkwmnBf01vnVaUO9C6/lToUa9i7r3BD3s6OQW24qz2ixieS3K6NxxxqMrVQ1 vFArleJIYA/FsDM2NPbeaUQA9z5GJj5X3FcPUPLLF+y5G/0HE14= =aBRL -----END PGP SIGNATURE-----

2 2

reproducible builds for Android tor daemon
by Hans-Christoph Steiner 17 Sep '19

17 Sep '19

Hey all, I'm currently working on tor for Android as part of a Guardian Project project. One key goal is making a shareable, reproducible build process for the tor daemon for Android. Then this would be published to MavenCentral as an Android AAR package to be used in all the apps that include tor (Tor Browser, Orbot, Briar, Thali, etc). I have cleaned up the existing build process a lot, so now I'm down to troubleshooting reproducible issues. First off, can anyone see any objections to switching Tor Browser, Orbot, Briar, etc. to use GPG-signed reproducible binaries via MavenCentral for the tor dameon? Second, I'd welcome pointers to the integration points in Tor Browser, Briar, etc. And third, and tips on getting a Linux shared library to build reproducibly. E.g. is faketime a hard requirement? And for those interested, the here's an overview of the whole project I'm tasked with: The basic idea is to make an Android-native TorService, which is a subclass of android.app.Service and loads tor daemon as a shared library, and starts it via JNI methods. This should be pretty close to how iOS apps use tor. Then that TorService should then plug into Orbot, Tor Browser, Briar, etc. Then based on that, I'll make a standalone, dead simple "TorServices" app that only provides Tor. No PTs, HSs, etc., just a tor daemon linked in as a shared library, providing a SOCKS and HTTP CONNECT proxy via tor. I hope to switch the ControlPort to use a UNIX domain socket. This then can also be embedded into Android OS ROMs that want to have Tor built-in as a system service, like CalyxOS. Then I'll be working on the apps choosing which tor provider to use, since we'll have a new TorServices, so apps that don't include Tor will have to figure out how to use Orbot and/or TorServices. Then that work will hopefully be extended into sharing tor between apps, e.g. letting Briar, Tor Browser, etc share the tor SOCKS proxy to other apps that want to use it. That would happen via Android mechanisms like Intents to manage the discovery of SOCKS ports. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

8 11

New Orbot, tor-android and AndroidPluggableTransport updates
by Nathan Freitas 17 Sep '19

17 Sep '19

A new Orbot is out, with a bug fix related to obfs4proxy installation, and a new tor! We've also updated the tor-android library, with the latest 0.4.1.5 release, and all is working well. https://github.com/guardianproject/tor-android/releases/tag/tor-android-bin… and we updated our AndroidPluggableTransports library, which was at the root of our "Orbot Bridge" bug, not properly installing the binary from the APK bundle. https://github.com/guardianproject/AndroidPluggableTransports/releases/tag/… These libraries and versions are available via our Guardian Project gradle/maven repo hosted on Github: maven { url "https://raw.githubusercontent.com/guardianproject/gpmaven/master" } implementation 'org.torproject:tor-android-binary:0.4.1.5-rc' implementation 'info.pluggabletransports.aptds:apt-dispatch-library:1.0.7' implementation 'info.pluggabletransports.aptds:apt-meek-obfs4-legacy:1.0.7' Everything is building again in our CI pipeline here: https://gitlab.com/guardianproject/orbot/pipelines and we nearly have automated on-device testing working via the cloud services Bitbar and/or Browserstack. Life is good, again. +n -------- Forwarded Message -------- Subject: Orbot 16.1.2 RC-2 with tor-0.4.1.5-rc Date: Tue, 10 Sep 2019 00:42:56 -0400 From: Nathan of Guardian <nathan(a)guardianproject.info> Organisation: Guardian Project To: Guardian Dev <guardian-dev(a)lists.mayfirst.org> Orbot 16.1.2-RC-2-tor-0.4.1.5-rc https://github.com/guardianproject/orbot/releases/tag/16.1.2-RC-2-tor-0.4.1… * Found and fixed bug related to bridges not working (https://github.com/guardianproject/orbot/issues/242) * Updated tor to 0.4.1.5 ARM64 APK: https://github.com/guardianproject/orbot/releases/download/16.1.2-RC-2-tor-… ARMEABI APK: https://github.com/guardianproject/orbot/releases/download/16.1.2-RC-2-tor-… @n8fr8 n8fr8 released this 5 minutes ago · 0 commits to master since this release c2e679d (HEAD -> master, tag: 16.1.2-RC-2-tor-0.4.1.5-rc) update to 16.1.2-RC-2-tor-0.4.1.5-rc 1d45a3d update APT Pluggable Transport library to 1.0.7 - this should fix one issue with installing the correct ofbs4proxy binary - also small changes to ensure no lock states and reduce log noise efec61d (tag: 16.1.2-RC-1-tor-0.4.0.4-rc, newport/master) update to 16.1.2-RC-1-tor-0.4.0.4-rc 237b388 yet another attempt at fixing the phantom zulu locale bug! a9efc3c disable tests for now in CI build 918bcca (origin/master, origin/HEAD) remove unused layouts for app-mini 08b670f update paths for app-mini code cefac58 putting classes back into main app package, and not "mini" 97d2aac improvements for bridge handling for #242 0e40c07 update badvpn tun2socks library 034844a remove fileprovider from app-mini since it is used just for HS d95f197 make keystore props reading not fail if not present d0640c6 remove output from repo e8f3158 remove binaries from repo 5845a4c update build tools to 29 003d9ea update build tools to 29 9c6de06 update build tools to 29 a266c65 add new functionality to allow for checking connections against app blacklist d98e5fb update changelog for 16.1.1-BETA-2-tor-0.4.0.4-rc-orbotservice Assets 6 Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-arm64-v8a-release.apk 10.3 MB Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-arm64-v8a-release.apk.asc 833 Bytes Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-armeabi-v7a-release.apk 9.94 MB Orbot-16.1.2-RC-2-tor-0.4.1.5-rc-fullperm-armeabi-v7a-release.apk.asc 833 Bytes

2 2

Network team: New status page for 0.4.2; feature freeze; want to work on any tickets?
by Nick Mathewson 16 Sep '19

16 Sep '19

Hi! This mail is mainly for the network-team folks, but I'm sending it to tor-dev anyway in case it's helpful to anybody else. I've made a new page for our 0.4.2 status, based on Teor's original 040 status page. Here it is: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… Note that as with 0.4.1, I'm using two different keywords: 042-must and 042-should. The difference here is that 042-must stuff should be things that would really block a release candidate, whereas 042-should stuff is stuff that we might in theory release without fixing. (It might annoy our users or violate our best practices, so we _should_ try to fix it, at least.) At the bottom of the page are all the tickets in the milestone that are *not* marked 042-must or 042-should. Some of these are things we could still fix anyway in 042; many will be removed. Please label them soon if you think they are things we should fix in 0.4.2! We are now in feature-freeze for 0.4.2.x. Let's try to solve our open 0.4.2.x issues soon, so that we can move on to 0.4.3.x. Most of the 042-must and 042-should issues are currently unassigned, so if there are any you would like to work on, please either assign them to yourself, or bring them up at the next team meeting? cheers, -- Nick

1 0