- tor-dev - lists.torproject.org

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

Re: [tor-dev] TBB Memory Allocator choice fingerprint implications
by procmem＠riseup.net 17 Aug '19

17 Aug '19

*On Sat, 17 Aug 2019 at**21:17, Tom Ritter* <tom at ritter.vg <mailto:tor-dev%40lists.torproject.org?Subject=Re%3A%20%5Btor-dev%5D%20TBB%20Memory%20Allocator%20choice%20fingerprint%20implications&In-Reply-To=%3CCA%2BcU71%3DPeZGCAJNsPQy9QpKY9%3Dwz3vPdW8QKruF_ZwyanoyYzQ%40mail.gmail.com%3E>> wrote: > On Sat, 17 Aug 2019 at 15:06, procmem at riseup.net <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev> <procmem at riseup.net <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev>> wrote: > >/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) / > Fingerprint what aspect of the browser/machine? I'm not really sure (I'm of the opinion it should not matter) and so I'm curious as to what could be affected if anything. Some members of our team are divided about making it the default because of unknown consequences which is what I'm trying to clear up. > >/We are thinking of switching Tor Browser to use the minimalist and />/security oriented hardened_malloc written by Daniel Micay. Thanks. / > I wouldn't advise giving up partitioning for.... what exactly? What > features does this allocator have that 68's jemalloc doesn't? > > -tom So the original suggestion [0] was prompted by past research done by the Tor Browser team for a jemalloc alternative. [1] Hardened_malloc wasn't around back then so it may be a worthy alternative for you guys to switch to too. Hardened_malloc has a partitioned heap among many other defenses implemented if I understand their label correctly (please see "Security properties" section in [2]). Also available on ARM. [0] https://forums.whonix.org/t/hardened-malloc/7474 [1] https://trac.torproject.org/projects/tor/ticket/10281 [2] https://github.com/GrapheneOS/hardened_malloc *** PS. A related debate is on whether we should enable Apparmor and Firejail sandboxing for Tor Browser by default, but again we don't know if restriction to resources and file paths on the machine is something that is remotely detectable as an anomaly or not, ruining the fingerprint in the process. Input is appreciated. related thread: https://forums.whonix.org/t/tor-browser-hardening-hardened-malloc-firejail-…

1 0

24 hours worth of BridgeDB usage metrics
by Philipp Winter 30 Jul '19

30 Jul '19

Over at <https://bugs.torproject.org/9316>, we are working on having BridgeDB export metrics. The patch is almost done and I deployed the work-in-progress code on BridgeDB, so we can take a look at the metrics and think of ways to improve them. The metrics format encodes the approximate number of requests per distribution mechanism per transport per country per success/fail. All numbers are rounded up to the next multiple of 10. The last field, "none", will be used for an anomaly score and is currently unused. For example, the line bridgedb-metric-count email.obfs4.riseup.success.none 10 tells us that there have been 1-10 successful email requests for obfs4 coming from Riseup addresses. I attached 24 hours worth of metrics to this email. Keep the following issues in mind: * My feature branch hasn't been reviewed yet and likely still has bugs, so take all numbers with a grain of salt. * The country codes are based on Debian stretch's geoip-database, which is slightly outdated and uses Maxmind's far-from-perfect GeoLite database. * The country code "??" refers to geo-location failure or lack of IP addresses (in the cast of moat). The country code "zz" refers to a request from a Tor exit relay. Some observations: * Gmail sees much more use than Riseup. That's no surprise. * The email distributor sees more vanilla than obfs4 requests. I wonder to what degree this is caused by the poor UX of the email distributor. * For HTTPS, many countries have a fail and success bucket of 10 each. I would expect this to be at least one user who failed the captcha at least once before finally getting it right. * The captcha success rate for obfs4 over moat is 54%. That's very low and must cause lots of frustration for users. This is a known issue that's tracked in this ticket: <https://bugs.torproject.org/29695> * Ignore the large amount of HTTPS requests from "zz" -- I expect the vast majority of these to be a bot that's interacting with BridgeDB over exit relays. After a cursory look at the numbers, I would like to aggregate the data, to make it easier to compare distributors, transports, and countries. For example: how do moat, email, and HTTPS rank in popularity? I'll improve the patch to keep track of these numbers in separate metrics. Any thoughts or suggestions? Cheers, Philipp

3 4

What hidden services does my relay node know about?
by clive.jenson＠tutanota.com 29 Jul '19

29 Jul '19

I built tor from source and am running it as a relay (not exit node) and also as a directory server. It is my understanding that after a while I should experience V2 hidden services publishing their descriptors to me (each hidden service picks 6 directory servers at random to publish their descriptor to). How can I tell if this is happening? Can I (temporarily, for debugging purposes) view the descriptors being published to me? I'm thinking their might be some useful logging if I enable debug logs (but I can't find it)? Or maybe there is something I can get over the control protocol (but I couldn't find anything obvious in the stem API docs that exposes it)? Or maybe I could make a code change to log this information (I'm not sure where the code is that receives the announcements)?

2 4

Hack
by Pordeshi Pothik 26 Jul '19

26 Jul '19

Hi,I want to learn how to hack facebook.

2 1

Proposal 306: Onion Balance Support for Onion Service v3
by David Goulet 25 Jul '19

25 Jul '19

Greetings! Around 4 months ago, nickm published a proposal draft for OnionBalance to support onion services v3. Due to #29583, it turns out that we can afterall take the easy approach which is basically how OnionBalance is working today for v2 but transposed to v3. See the ticket for the reasons why for now we'll proceed this way. However, we all agreed that #29583 is a "must fix at some point" meaning that OnionBalance v3 will then become much more complicated. In order to not forget about it, I'm reviving nickm's proposal as prop306 so we have the draft in torspec.git. See attachement for the proposal. Cheers! David -- vjZrE+FHHEPpllrbcUukx7LtWFzk066L23yoggvnmso=

3 2