- tor-dev - lists.torproject.org

Non-endorsed methods for accessing Tor hidden services
by Rishab Nithyanand 11 Sep '19

11 Sep '19

Hi Tor-Dev, I'm sending this message on behalf of Hammas, one of my PhD students at UIowa, who has been unable to get his emails past moderator approval. Hammas and I have been recently working on the implications of visiting the Tor hidden services through services not endorsed by Tor itself. The goal is to see if they're doing things that might deanonymize a user. Currently, we've only found a handful of Tor2Web websites and extensions. I have found injected HTMLs containing common trackers and tweaks in request headers which might cause serious privacy harm. We want to be more thorough in our study of this ecosystem and were hoping that you all might be aware of some non-Tor-endorsed extensions, websites, apps, or services that we should test. No matter how popular or obscure, please let me know! Thanks for your time and help! Best, Rishab

1 0

txtorcon 19.1.0
by meejah 10 Sep '19

10 Sep '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm pleased to announce txtorcon 19.1.0, containing the following changes: * TorControlProtocol.on_disconnect is deprecated in favour of TorControlProtocol.when_disconnected * introduce non_anonymous_mode= kwarg in txtorcon.launch() enabling Tor options making Onion Services non-anonymous for the server (but they use a single hop instead of three to the Introduction Point so they're slightly faster). * add an API to listen to individual circuit and stream events (without subclassing anything). Can be used as decorators too. See e.g. TorState.on_circuit_new() * fixes to the CI setup to properly test Twisted versions You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/19.1.0 https://github.com/meejah/txtorcon/releases/tag/v19.1.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-19.1.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-19.1.0.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 25d8e52c3eac45bb90ff958ca7cdd7674fb3284e3a50826a58ab7b9578b15ea5 dist/txtorcon-19.1.0.tar.gz e93aef50f339b537ed969a4d83a704a2870658bb49cdfa95495ba5a740548d32 dist/txtorcon-19.1.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAl13SBcRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaad/DwgA5r1XbcoPuzw2FSoDNwJNNzDSEFBT+W7Z Ej0Wp27B7KuUgCp83u08DWpCbuz1iOLiYveWtKil+CrXFpmxH2M9itF4pd3U71dt o/PfEnPy3OxWD1cka2bnuFO3HlmCs7LOy5KndRlWBSzqDXfqnwTLqNSHB94TMoh3 YEhyKmyo30DwLMeNdeayuJ18c24+U15kxt5+O7TPKSeNw88emizDMX3ZQFnuIUyJ 6ybZxIwkJxXLOlO+cqnLH26eSIFqHrvILTXPvZ3ie2cwNYOgNS4IpkmVUlrF41Zq xQgMdR1pzLWrEVMSPOYKicAnPW/drd8urwXMq5y2/dVuUhQmhHxBxg== =7R7N -----END PGP SIGNATURE-----

1 0

New Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs
by neel＠neelc.org 06 Sep '19

06 Sep '19

Hi tor-dev@ mailing list, I have a new proposal: A Tor Implementation of IPv6 Happy Eyeballs This is to implement Tor IPv6 Happy Eyeballs and acts as an alternative to Prop299 as requested here: https://trac.torproject.org/projects/tor/ticket/29801 The GitHub pull request is here: https://github.com/torproject/torspec/pull/87 Thank You, Neel Chauhan === https://www.neelc.org/

7 18

Orbot 16.1.1... now with 64-bit tor
by Nathan Freitas 05 Sep '19

05 Sep '19

Orbot 16.1.1 was just pushed out publicly to everyone on Google Play after a long multiple RC and beta period. YES, Orbot is still going to exist, with a really exciting roadmap ahead. More on that soon! Thanks to @bitmold @sisbell @pgerber and @eighthave for all the great work, not to mention the core Tor dev team making all things mobile better every day! Highlights include: * True arm64 tor binaries now! * Key fixes to VPN mode to handle loss of network access * Improvements to Tor idle/sleep behavior and resume after network drops ... and much more! Github (with APKs): https://github.com/guardianproject/orbot/releases/tag/16.1.1-BETA-2-tor-0.4… APK: https://guardianproject.info/releases/Orbot-16.1.1-BETA-2-tor-0.4.0.4-rc-fu… (.asc) F-Droid: soon! /** 16.1.1-BETA-2-tor-0.4.0.4-rc / Wed Aug 7 13:33:30 2019 -0400 / bbf5fcb3fb346e9bba712d12bf4934cf925cb2bd **/ bbf5fcb3 (tag: 16.1.1-BETA-2-tor-0.4.0.4-rc) update service for VPN mode and startup fixes ea7f3f10 update gitignore cf19750d update fastlane and gradle to support split apks builds, CI and more cd80e850 (tag: 16.1.1-BETA-1-tor-0.4.0.4-rc) update to 16.1.1-BETA-1-tor-0.4.0.4-rc bfb5eab1 Merge branch 'master' of github.com:n8fr8/orbot d02fb582 instead of DisableNetwork, let's try NEWNYM when the network returns - we've had issues of losing connectivity setting DisableNetwork, so we are trying a new approach - now using DormantClientTime out settings, to have client go to sleep when it is not used - when we receive a network connectivity notification, we call NEWNYM to refresh circuits d5e570a5 Merge pull request #247 from bitmold/low_dpi_launcher_icon 767a8596 Launcher icon was out of date on low resolution devices. 7d11984b (tag: 16.1.0-RC-3-tor-0.4.0.4-rc) update to 16.1.0-RC-3-tor-0.4.0.4-rc e146f703 make sure to kill existing pdnsd, and set the new ports properly c6bfc491 send ports on start request, even if tor is already running d3963516 keep apps around as static variable, enable user to refresh be5b8d88 make sure we don't have any orphaned pdnsd processes 72ff7dd2 Merge branch 'ejo4041-mergeDebugJniLibFolders_issue' 07e34239 (ejo4041-mergeDebugJniLibFolders_issue) Merge branch 'mergeDebugJniLibFolders_issue' of https://github.com/ejo4041/orbot into ejo4041-mergeDebugJniLibFolders_issue be6feea8 Merge branch 'master' of github.com:n8fr8/orbot d2005234 update gradle 929cb6b6 pdnsd must be named with a .so extension to be included c0afffeb don't build plain armeabi anymore 4321ae49 update native libs c7e9b01f Merge pull request #244 from bitmold/vpn_app_ui_glitch fc0b035a After following the BUILD file, could not build the apk because of a issue mentioned in #217: Execution failed for task :orbotservice:mergeDebugJniLibFolders. This change fixes that. 7b832f19 Fixed VPN App UI for apps that were disabled or uninstalled d084aa6c (tag: 16.1.0-RC-2-tor-0.4.0.4-rc) update to 16.1.0-RC-2-tor-0.4.0.4-rc 79afbe05 bind pdnsd to virtual address within VPN 9ff0b00c fix VPN code to support dynamic DNS port for Tor f1e572e8 use standard string keys for intent values 361ea26d ports can be set to "auto" so allow letters as well /** 16.1.0-RC-1-tor-0.4.0.4-rc / 8 July 2019 / e60c07ed0ffc8360db4dfcdeffd8578945b38d0b **/ Thanks to @bitmold @sisbell @pgerber and @eighthave for all the great work, not to mention the core Tor dev team making all things mobile better every day! e60c07ed (HEAD -> master, tag: 16.1.0-RC-1-tor-0.4.0.4-rc, public/master, origin/master, origin/HEAD) update to 16.1.0-RC-1-tor-0.4.0.4-rc 9e54cd6e set PDNSD server IP to 192.168.200.1 for local VPN network 0.0.0.0 allowed outside access to DNS port in some cases b7d100ca fixes #239 #229 #227 #205 and other VPN / DNS issues moved PDNSD daemon to load from the .so native path f9c1486c Merge pull request #241 from bitmold/fix_hs_dialog_crash f1b00157 Merge branch 'sisbell-sisbell_236a' 65ee380d (sisbell-sisbell_236a) Merge branch 'sisbell_236a' of https://github.com/sisbell/orbot into sisbell-sisbell_236a 1c386959 Fixes #236: Separate Constants For VPN, TOR and MAIN_APP ce85e951 Fixed crash I introduced with the NoPersonalizedLearningEditText 324b35ea (tag: 16.1.0-BETA-6-tor-0.4.0.4-rc) update to 16.1.0-BETA-6-tor-0.4.0.4-rc b6135386 Merge branch 'sisbell_236a' of https://github.com/sisbell/orbot into sisbell-sisbell_236a 124273fd (newport/master) Merge branch 'sisbell-sisbell_237' 43d807fd (sisbell-sisbell_237) remove minSDK from OrbotService manifest 45369a2a Merge branch 'sisbell_237' of https://github.com/sisbell/orbot into sisbell-sisbell_237 4a79476e Merge pull request #234 from bitmold/vpn_request_cancel_bug_fixes b0cf7424 Merge pull request #233 from bitmold/no_vpn_refresh_btn e448c18b Merge branch 'bitmold-remove_orfox' f3211aca Fixes #236: Separate Constants For VPN, TOR and MAIN_APP 8c232f73 Fixes #237: Upgrade to Gradle 5.x 2ebd3384 Fixes VPN Request Cancel Bugs cde49d1a Removes the refresh button on the VPN Selection screen 351ef96f (bitmold-remove_orfox) Removes references to Orfox since it is being completely replaced with the Tor Browser for Android. Conversations surrounding this can be found here https://blog.torproject. org/comment/281767#comment-281767 and here https://trac.torproject.org/projects/tor/ticket/29955 656d39b7 (tag: 16.1.0-BETA-5-tor-0.4.0.4-rc) update to 16.1.0-BETA-5-tor-0.4.0.4-rc 814fbb31 reset default ports to 9050, 8118 but make them dynamic if needed - ports will be checked and if not available, increment +1 - new setting add to allow static setting of http port value 827b905e ensure we are putting the right value in 144a4ed5 small change to attempt to address localization glitches c4062678 Merge branch 'master' of github.com:n8fr8/orbot ecdff5ce remove unused settings for root and transproxy 811c09aa Merge pull request #226 from bitmold/removed_unused_eclipes_prefs_folder 0361fb9a Merge pull request #225 from bitmold/missing_hidden_service_str 510118eb Merge branch 'master' of github.com:n8fr8/orbot f0103bf4 Removed unused Eclipse IDE settings files. I think there are old Eclipse build files in the root of the repository that should also get deleted but I'm not 100% sure if some of them are still used or not 768bbf94 The string resource "hidden_service_request" was missed in the "hidden service" to "onion service"rename in #222 53940073 Merge pull request #223 from bitmold/farsi_settings_crash_no_custom_prefs f0eede1d Merge pull request #222 from pgerber/onion-service aea140cf Merge pull request #221 from pgerber/dns-ttl 7887e119 fixes Farsi settings crash f58ef4c0 (tag: 16.1.0-BETA-4-tor-0.4.0.4-rc) update to 16.1.0-BETA-4-tor-0.4.0.4-rc dd3a8b0b improve how bridge lines are configured 553528cb make sure to use the request shell for exec() 1f36689b make sure we set HOME env variable some devices don't have it for their sh commands dc942cde Rename hidden services to onion services 2a0a116c Fix onion service only working intermittently in VPN mode 77d979cd (tag: 16.1.0-BETA-3-tor-0.4.0.4-rc) update to 16.1.0-BETA-3-tor-0.4.0.4-rc eb13e155 don't use 'UpdateBridgesFromAuthority' as it seems to cause a hang 67b69164 update built-in bridges 97a32ccf add ' UpdateBridgesFromAuthority' to help keep people connected to bridge aeb54c7e (tag: 16.1.0-BETA-2-tor-0.4.0.4-rc) update to 16.1.0-BETA-2-tor-0.4.0.4-rc 6dffafcb add dynamic display of SOCKS and HTTP port proxy value 397391f0 remove hardcoded port values, make it all dynamic /** 16.1.0-BETA-1-tor-0.4.0.4-rc / 31 May 2019 / 417e4fcd0720be57328d63a96d2c9fc0e119330f **/ Thanks to @bitmold @sisbell and @eighthave for all the great work, not to mention the core Tor dev team making all things mobile better every day! 417e4fcd update version to 16100003 aka 16.1.0-BETA-1-tor-0.4.0.4-rc 7ae000d0 fix pdnsd/VPN support dde1957d Merge pull request #219 from bitmold/delete_minimalperm_manifest a251d52f Merge pull request #218 from bitmold/ndk_app_platform_warning eda464bb remove incorrect torFile assignment a1c5806a update tor-android to 0.4.0.4-rc ad2e875b We no longer use the minimalperm product flavor so there's no need to keep this manifest file in app/src 917e49f5 Removes warning on ndk-build where the target API for NDK (16) is greater than the sdk version defined for the project. Since nothing was specified in the manifest it defaulted to 1 but we can set this to Orbot's minSdkVersion of 16 to get rid of this warning f83a98f4 Merge branch 'sisbell-issue_199' ff7d3dd5 (sisbell-issue_199) Merge branch 'issue_199' of https://github.com/sisbell/orbot into sisbell-issue_199 7c2cfc3e Merge pull request #212 from sisbell/issue_211 1316fd65 Merge branch 'bitmold-no_personalized_learning_kb' e3fd4afa (bitmold-no_personalized_learning_kb) Merge branch 'no_personalized_learning_kb' of https://github.com/bitmold/orbot into bitmold-no_personalized_learning_kb aa8ad867 Merge pull request #204 from bitmold/unreferenced_classes 16826a49 Merge branch 'bitmold-removed_obsolete_version_checks' 17154609 (bitmold-removed_obsolete_version_checks) Merge branch 'removed_obsolete_version_checks' of https://github.com/bitmold/orbot into bitmold-removed_obsolete_version_checks 0e4b42a7 add close bracket 4cee987c Merge branch 'master' into removed_obsolete_version_checks 08c35bd3 Remove unused resources. ae4ce1c9 Fixes #211: Resource Not Found on Command Line Build 2fb7e05a Merge pull request #210 from eighthave/fastlane 57120100 rename all metadata locale dirs after the Fastlane/Play names baced180 setup Fastlane to upload to Google Play d2feefdd Removed Obsolete @TaretApi Annotations for API Levels that are lower than Orbot's minimum, API Level 16 a32452e7 Make text inputs in Orbot declare that they do want to opt out of IME personalized learning. Of course, IMEs may ignore this request, but it's a nudge in the direction of Tor's general philosophy on user privacy, particularly with regards to minimizing the footprint that a Tor app leaves on the user's device. 7d8e41a6 Removed Constraint Layout Dependency 5d04d418 Removed Unused Classes 2b6abd7e Removed Obsolete Version Checks cd6560fa Merge pull request #202 from bitmold/no_constraint_layout a5d5c99f (public/master, gl/master) remove unused launcher art 9257b66f don't shrink or minify for now 56917567 (tag: 16.0.6-BETA-2-tor-0.3.5.8) many small changes to support new binary loading, startup and more - improved handling of port conflicts - fixed loading of tor binary on arm64-v8a - changed how w e execute shell commands 8ed080f9 Removed Constraint Layout Dependency 2a76b7af (tag: 16.0.6-BETA-1-tor-0.3.5.8) updated to SDK 28, added android.permission.FOREGROUND_SERVICE permission fb14c76c fixed strings with two many \\ escapes 45575772 updating to tor-0.3.5.8-rc to add support for Android Q 22d5ffdf update gradle tools 76796fea Merge pull request #200 from eighthave/fastlane-supply 6ba0cecc add .gitlab-ci.yml setup with errorprone 3face00a build gradle to 4.4.1, and make gradlew verify the download 69bd7fe9 move app store graphics into fdroid/fastlane file layout f93c11e7 Merge pull request #190 from SkewedZeppelin/master 8ab13f63 Fixup bad indentation from 6e4b7008 12b91c44 Expose PreferIPv6 and NoIPv4Traffic options 8ad76680 Move Google repo above jcenter d4befad1 cleanup and binary loading fixes 2d4e2a5f update tor to 0.3.5.6-RC 0f314214 (tag: 16.0.5-RC-2-tor-0.3.4.9) update to 16.0.5-RC-2-tor-0.3.4.9 2c59c848 ensure startForeground() is always immediately called - since we use startForegroundServce() we must ensure the receiving service complies! _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscribe(a)lists.mayfirst.org

1 0

Re: [tor-dev] Q: Links to external apps
by LA_FORGE 29 Aug '19

29 Aug '19

Thanks. I tried that already and also completely uninstalling the NoScript Addon and moved the security slider of TB to the lowest level but it doesn't work :( ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, August 29, 2019 5:12 AM, Kaizu Shibata <kaizushi(a)cock.li> wrote: > Try turning on Javascript. > > LA_FORGE: > > > Hi, > > I love Tor Browser very much. So much that I just created a separate TB instance for local Intranet browsing. Everything is working fine but I just got a question related to links to other/external applications such as vmrc://192.168.76.224/?moid=36 > > It's from the VMware ESXi Webclient. I just set up a handler at 'Applications' in TBs Options and made it permanent: > > [TB_Applications.png] > > but it doesn't work :( the external application won't start :( Does TB have a protection against those links to external applications? If so. is there a way to turn it off? > > Thanks in advance > > Greetings > > LA_FORGE > > > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -- > > Owner of Kaizushi's Little Onion Server and Infantile. > > http://kaizushigdv5mrnz.onion/ > http://infantilefb6ovh4.onion/ > > Main email: kaizushi(a)infantile.us > Others: kaizushi(a)infantile.xyz kaizushi(a)cock.li kaizushi(a)secmail.pro

1 0

Q: Links to external apps
by LA_FORGE 28 Aug '19

28 Aug '19

Hi, I love Tor Browser very much. So much that I just created a separate TB instance for local Intranet browsing. Everything is working fine but I just got a question related to links to other/external applications such as vmrc://192.168.76.224/?moid=36 It's from the VMware ESXi Webclient. I just set up a handler at 'Applications' in TBs Options and made it permanent: [TB_Applications.png] but it doesn't work :( the external application won't start :( Does TB have a protection against those links to external applications? If so. is there a way to turn it off? Thanks in advance Greetings LA_FORGE

1 0

Putting onion services behind a third-party TCP proxy
by Pop Chunhapanya 27 Aug '19

27 Aug '19

Hi all, When deploying an onion service, I noticed some problem that the ip address of my machine that runs tor daemon is exposed to the Tor network which is vulnerable to the DDoS attack if someone knows my ip address. So I'm thinking putting the tor daemon behind some third party TCP proxy that will protect me from this kind of DDoS attack. What do you think if I want to implement a feature that forward all the onion service traffic to the TCP proxy before going to the Tor network? The protocol that I'm thinking is TCP Proxy Protocol [1] [1] https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

4 9

Enhanced Tor Browser sandboxing upstreaming
by procmem＠riseup.net 24 Aug '19

24 Aug '19

Hi. We aim to make enhanced sandboxing for Tor Browser widely available on Linux that's well maintained in the long term. We would appreciate it if TBB team provides the currently developed Apparmor and firejail profiles below from your repos and run unit testing and check/fix any breakages with updated browser versions. It turns out there is an advantage to stacking both Apparmor and Firejail. Firejail doesn’t offer nearly as good file path whitelisting as AppArmor. Firejail also can’t do many things AppArmor can such as managing ptrace or signals, yet firejail can use xpra to isolate Tor Browser's access to X, pulseaudio and the clipboard. The Firejail package included in Debian stable cannot keep pace with the needed changes as Tor Browser continues to change. Stacking is also a good defense in depth. If there’s a vulnerability in Firejail then AppArmor will still restrict the application or vice versa. Firejail provides a maintained official profile for Tor Browser [0]. We have a Apparmor profile that we've maintained for years [1]. [0] https://github.com/netblue30/firejail/blob/master/etc/start-tor-browser.pro… [1] https://github.com/Whonix/apparmor-profile-torbrowser

1 0

TBB Memory Allocator choice fingerprint implications
by procmem＠riseup.net 21 Aug '19

21 Aug '19

Question for the Tor Browser experts. Do you know if it is possible to remotely fingerprint the browser based on the memory allocator it is using? (via JS or content rendering) We are thinking of switching Tor Browser to use the minimalist and security oriented hardened_malloc written by Daniel Micay. Thanks.

10 17

[prop305] Introduction Point Behavior
by David Goulet 20 Aug '19

20 Aug '19

Greetings, This is part of the many discussions about proposal 305 which is the ESTABLISH_INTRO DoS defenses cell extension. Implementation is close to done and under review in ticket #30924. However, there is one part that is yet to be cleared out. asn and I thought it would be better to bring it to tor-dev@ to get a more informed decision. As a reminder, the service operator will be able set torrc options that are the DoS defenses parameters. Those values are validated (bound check) and then sent to an introduction point, supporting the extension (protover HSIntro=5), in the ESTABLISH_INTRO cell. The intro point then gets them and apply them only to that specific circuit. If no cell extension is seen, the intro point will honor the consensus parameters for these DoS defenses. What we want to discuss is what happened when the introduction points receives bad values. What does it do with the circuit? Below is the list of possible bad values and the proposed behavior: 1) One of the paramater (at this point in time, only 2 exists) is out of bound that is above INT32_MAX. Behavior: We propose to ignore the cell extension, and fallback to follow the consensus parameters. Keeping the circuit alive and working. The reason for this is because if let say the intro point would close the circuit due to "bad protocol", then the service would open a new circuit to an intro point supporting the extension and it would fail again. Effectively turning the service into a "zombie" and "DoS" weapon itself ;). At this point, there is really no reason on why the service would send bad values since torrc options are validated and then sent to the intro point. But this doesn't protect us from our future-developer-self making coding or protocol mistake ;). 2) A parameter type is unrecognized. This one is mostly about forward compatibility. Behavior: Ignore the parameter type, and continue parsing the cell extension. If all the right parameters are found, apply defenses. 3) None or 1 parameter out of 2 is given. Behavior: This would be considered bad protocol so it would be like (1) where the intro point uses the consensus parameters. 4) <insert whatever case you can think about> So, for (1) and (3), there lies mostly the discussion. There is no way to send feedback to the service if a problem occurred and that the DoS defenses weren't applied due to reason X. If we had that, we could not only try to warn the operator (log or control event) but make tor smarter when an error is returned so it doesn't try to infinity other intro points with values that makes them fail. One avenue there is to pass down such error code into the INTRO_ESTABLISHED cell with probably a new extension. That requires more work and likely either extending prop305 or a new proposal. Thus, what is the minimal viable product here we are ok with? I'm leaning towards not closing the circuit and falling back on the consensus parameters. And at some point in time, we'll be able to implement the INTRO_ESTABLISHED response. In the meantime, there is little chances that tor vanilla start sending bad values since they are validated from the torrc file. Cheers! David -- eHE50zZRZOX3zLNHdPwN5gGQBUvDnfGyOuYr/afK2XY=

3 2