- tor-dev - lists.torproject.org

Onion Service Intro Point Retry Behavior
by David Goulet 01 Nov '19

01 Nov '19

Greetings everyone, After some discussions between arma, mikeperry, asn and I, it is time for a famous tor-dev@ email thread to try to get to a consensus if need be. In the past weeks, a set of HSv3 reachability issues have been found regarding *service* intro points (IP): - hs-v3: Service can keep unused intro points in its list https://bugs.torproject.org/31561 - hs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro points https://bugs.torproject.org/31548 - hs-v3: Stop using ip->circuit_established flag https://bugs.torproject.org/32094 - hs-v3: Client can re-pick bad intro points https://bugs.torproject.org/31541 - hs-v3: Service circuit retry limit should not close a valid circuit https://bugs.torproject.org/31652 Long story short, couple weeks ago we've almost merged a new behavior on the service side with #31561 that would have ditch an intro point if its circuit would time out instead of retrying it. (Today, a service always retry their intro point up to 3 times on any type of circuit failure.) And here comes the core of the discussion of this thread: Retrying intro point on failure or simply ditch it on failure and pick a new one? Some 7 years ago, this ticket was created and thus we implemented roughly 4 years ago a mechanism that makes a service retry to establish the intro point circuit up to 3 times when it collapses (except for very very specific cases for which we wouldn't): https://bugs.torproject.org/8239 HSv3 tried to be on feature parity there with v2 up until now that the above bugs have been mostly fixed. That being all said, regarding the retry feature, there are pros and cons. I'll try to organize them below based on many adhoc discussions in the past and what I can get from all the tickets up to this day (there could be more! this is just what I could recall and find in the tickets): == Pros == The primary original argument for retrying is based on the mobile use case. If a .onion is running on a cellphone and the network happens to be bad all the sudden, the service is better off to re-establish the intro circuits which would make the retry attempts of the client to finally succeed after a bit instead of having to re-fetch a descriptor and go to the new intro points. Thus, in theory, it is mostly a reachability argument. One question that can arise from this is: Will the client be able to reconnect using the old intro points by the time the service re-established? In other words, is the retry behavior of the *client* allows enough time for the service to stabilize for the mobile use case? I'm curious to learn from people with experience with this! == Cons == Recently, mikeperry raised concerns about the retry behavior all together and proposed to simply ditch each time the intro point instead of retrying. (@Mike, I do invite you to comment here as you mentionned many times rationales for this but I don't have enough IRC backlog :S). == Pros _and_ Cons at the same time == There is a possible Guard discovery attack argument against retrying. But it is nuanced on what exactly constitute a failure and when should it retry vs ditching. Quote from https://trac.torproject.org/projects/tor/ticket/8239#comment:6 FWIW, it's also worth mentioning that making HSes more stubborn towards old IPs might also allow guard discovery attacks from the IP. That is the IP kills incoming circuits, till a compromised middle node is selected, and since the HS is stubborn it will keep on establishing new circuits. This was mentioned by waldo here: https://lists.torproject.org/pipermail/tor-dev/2014-May/006843.html ... which is where the "what is the failure" is important as arma's mentions in the same ticket: That's why you should only stick to your intro point when it's your network that failed (that is, the connection between you and your guard), not the intro circuit. (This is what I meant in the body of the bug in the 'main tricky point' sentence.) We had this discussion before in Tor many times on "how to detect network failures" vs "circuit failures". In other words, if the link to your Guard fails, that would be enough to consider a network failure and thus retry the intro point. But if the circuit collapses due to let say a DESTROY or TRUNCATED cell, then it could be the IP closing it for the purpose of an attack and thus you would select a new intro point. But, it could also be that the middle node died... That one has many false positive. Soooooo, to repeat what I first said at the beginning, today an HSv3 will _always_ retry up to 3 times regardless of the reason why the circuit collapsed. Should that behavior get more refined with the network failed vs circuit close argument? Should we stop at once retrying? Should we change the retry behavior client side to better match the latency of the mobile use case? Whatever we decide, most importantly, we need to document the *why* of this retry/ditch behavior and thus this email thread is I hope a good start to keep a record of the discussions/arguments. Cheers! David -- 5qZaRu0+AqSNqiaTmTpzcIEztqeYQIq7AAfzKdg/2cs=

2 1

New python Tor client implementation
by James Brown 24 Oct '19

24 Oct '19

4 4

Comparing Proposals 295 and 308
by Tomer Ashur 23 Oct '19

23 Oct '19

Dear all, Some time ago I sent to this mailing list a proposal for using the ADL construction to solve the crypto tagging attack and it was registered as Proposal 295. Then, about a month ago Jean Paul Degabriele sent another proposal aiming for the same, which was registered as Proposal 308. We’ve now had the chance to compare both proposals and we provide our observations below. But before we discuss the pros and cons of each proposal, I’d like to re-state our goal for Proposal 295. Our aim was to build something that: 1. does not lose any security guarantees that are already in place; 2. prevents successful crypto-tagging; and 3. does not introduce new weaknesses. We *did not* consider advanced security goals such as forward secrecy and/or non-repudiation which was also mentioned earlier on this mailing list. In achieving these goals, the two proposals are almost the same: for the encryption part, both use layered encryption where the nonce is tweaked with a digest of the ciphertext, and sent in encrypted form to the next node as part of the ciphertext. The only meaningful difference I could find is that instead of using the output of the universal hash function (i.e., GHASH) as a running digest as is done in Proposal 295, Proposal 308 uses the encrypted nonce. Jean Paul made the correct observation that our security proof did not account for key-dependent input, but we believe that this can be resolved by rewriting the proof. In either case, this is a subtlety and common ground can be found. On a high level, both proposals use the same mechanism to avoid crypto-tagging. Where the proposals differ is in the authentication part. Proposal 295 makes a functional separation between the encryption part and the authentication part, cf. Lines 150-152 (authentication) and Lines 156-160 (layered encryption). Conversely, Proposal 308 does not offer such separation, and the authentication and encryption of the last node are done in a single pass (cf. Lines 227-230 and Lines 244-252). This comes with what we think are two highly unwanted side effects defeating the purpose of using the ADL construction to begin with: the authentication of the last node depends solely on the proper execution of the IF statement on Line 266. As a result, if this line is skipped for some reason (e.g., because an adversary corrupted the last node, a bug, or as a result of over-optimization), modified messages may leave the network. Moreover, the last layer is malleable which means that a difference introduced to the ciphertext entering the last node will be preserved through the final decryption (given that the IF statement on Line 266 is skipped). This is because the decryption nonce does not depend on the authentication process (in the lingo of Proposal 308 this is called a “dynamic nonce”). Comparing this to Proposal 295 we see that the same cannot happen. Any change introduced at any point (including the ciphertext entering the last node) will completely destroy the payload in an irrecoverable way (the same happens in the “static layers” of Proposal 308; only the dynamic layer is malleable). For the record, a corollary of all of this is that if Sf_I is leaked (e.g., via a side channel in the generation process of Nf_I that is used by the IF statement), the adversary now has the secret it needs to decrypt the ciphertext regardless of the authentication process. Not being able to do this is exactly what’s captured by the RUP property used in Proposal 295 in which the only way to obtain N_4 (the counterpart of Proposal 308’s Nf_I) is via a successful digest of an unmodified ciphertext. The place where Proposal 308 nicely extends over Proposal 295 is in the forward secrecy domain. In an email to this mailing list we conjectured that if certain changes are made to Proposal 295 it will provide forward secrecy in addition to its crypto-tagging resistance. Jean Paul suggested an attack against this conjecture, but I find that the attack is not very convincing. Indeed, once the keys are leaked, the last message can be recovered. But I don’t think that there’s anything surprising in the fact that the set of keys that would have normally decrypted a message will also do so if leaked to an adversary. A more reasonable definition for forward secrecy would be that no message can be decrypted *after* the state (including ephemeral secrets) that was used to generate this message was replaced. Admittedly, Proposal 308 replaces this state earlier than Proposal 295 (immediately after processing the message vs. after processing the next message), which may be desirable, but is anyway not disastrous. That being said, this discussion is theoretic in nature since of the two proposals, only Proposal 308 offers an actual mechanism. For Proposal 295 we only offer a conjecture. We also tend to somewhat agree that frequent re-keying is a better way to achieve forward secrecy. Regardless of which is the better way, both can be built on top of the encryption mechanism we offered in Proposal 295 whose goal is to resist crypto-tagging. In the interest of moving forward we propose to implement Proposal 295 as suggested or something close to it (e.g., using POLYVAL) to counter crypto-tagging, then discuss alternatives to achieving forward secrecy and add those on top of the ADL construction via Proposal 308. A few side notes: 1. Proposal 308 argues that POLYVAL is more suited than GHASH to our this use-case. This is an implementation issue. GHASH or POLYVAL or any other collision resistant hash function are all the same to us. 2. I'm pretty sure there's a typo on Line 250 in Proposal 308 and that the text should be Y_I = Tf_{I+1} ^ X_I. Otherwise, I can't see how the protocol decrypts on Line 285. 3. The lengths in Section 2.2 (marked for revision) are given in bytes, but then in Section 2.3 they are treated as bits. 4. Line 230 has unbalanced parenthesis. Tomer

2 1

Optimistic SOCKS Data
by Tom Ritter 15 Oct '19

15 Oct '19

The attached is a draft proposal for allowing tor to lie to an application about the SOCKS connection enabling it to send data optimistically. It's going to need some fleshing out in ways I am not familiar with, but I wanted to get something out to start as we think that this is probably the best path forward for bringing back Tor Browser's optimistic SOCKS behavior. -tom

6 11

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

Preferred compression type?
by Steve Snyder 13 Sep '19

13 Sep '19

Given the multiple compression types supported (none, lzma, zlib, zstd), what is the order of preference for runtime use? Put another way, which compression method(s) should be supported to get optimal runtime performance from a Tor node? Thanks.

2 2

Compile warns
by grarpamp 12 Sep '19

12 Sep '19

freebsd 12 x64 gcc 8.3.0 src/core/or/connection_edge.c:2563:5: warning: potential null pointer dereference [-Wnull-dereference] src/lib/math/fp.c:106:16: warning: conversion from 'double' to 'float' may change value [-Wfloat-conversion] src/lib/math/fp.c:111:18: warning: conversion from 'double' to 'float' may change value [-Wfloat-conversion] src/lib/math/fp.c:136:16: warning: conversion from 'double' to 'float' may change value [-Wfloat-conversion] src/lib/math/fp.c:88:13: warning: conversion from 'double' to 'float' may change value [-Wfloat-conversion]

3 5

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