- tor-dev - lists.torproject.org

GSoC 17 | Name System API for Tor Onion Services
by Pickfire 29 Mar '17

29 Mar '17

Hi, I am Ivan Tham. Currently studying in Computer Science in APIIT Malaysia. I am interested particapate in Google Summer of Code 2017 under tor organization. I am interested to see Proposal 224 coming along but I would really like to see [Proposal 272][0] and hope that tor hidden services can be more user-friendly. What do you think of the projects? Is the proposal too immature? I had looked into [OnioNS][1] as well and like the idea of having different types of DNS records for tor hidden services, how does it integrate with [Proposal 272][0]? [0]: https://lists.torproject.org/pipermail/tor-dev/2016-October/011524.html [1]: https://lists.torproject.org/pipermail/tor-dev/2015-May/008826.html

4 5

Issues With Ticket #7532 - "Count unique IPs in an anonymous way"
by samir menon 28 Mar '17

28 Mar '17

This ticket [1] was suggested as a GSoC project, but I think there might be an issue with the security model/perceived threat. To summarize the ticket and its child [1], basically, we currently store all the IP's seen by a node so that we can count unique IP's. The idea is that this is dangerous; if a node is compromised, then all of those IP addresses can be retrieved from memory. Therefore, a variety of mitigation methods have been proposed (most prominently, the 'Probabilistic Counting Algorithm' from [2]) Here's my issue: what about brute force? No matter what method we use, we will arrive at a data structure that should be able to, given an IP address, tell us whether it is new (and we should increment the unique counter) or old (and we should leave the unique counter the same), with some reasonably small false positive rate. Basically, we're supposed to use some kind of Bloom filter like structure. Then can't that structure then be brute-forced, offline, by an attacker? IPv4 addresses are 32-bits (~4.3 billion of them), so an attacker could just run whatever method we use to check membership over and over, and then recover the set of IP's. The same happens if we hash the IP's beforehand. So, is this attack acceptable? The only mitigation I've seen is the one referenced by 'Aaron' in the ticket, which is the system that git uses, cryptolog; there, they have a random salt that changes daily. Then, an attacker can only learn the IP's for one day. This sounds like a reasonable compromise to me, but then the implementation becomes rather simple; just hash the IP's with a random salt that changes daily before putting them in the set. IPv6 also solves this (128 bits), but there again, the solution is just to hash the IP's before storing them - the Bloom filter/'Probabilistic Counting Algorithm' is unnecessary. I think I must be missing something about how the 'Probabilistic Counting Algorithm' works - somehow, it needs to keep track of the # of unique IP's without knowing (with a high probability) whether any 1 individual IP has been seen. Any help/pointing out of errors in my reasoning would be useful. Thanks, Samir Menon menon.samir(a)gmail.com samir2(a)stanford.edu [1] https://trac.torproject.org/projects/tor/ticket/7532 [2] http://www.mathcs.emory.edu/~cheung/papers/StreamDB/Probab/1985-Flajolet-Pr…

3 3

[RFC] Proposal for the encoding of prop224 onion addresses
by George Kadianakis 28 Mar '17

28 Mar '17

Hello list, we've had discussions over the past years about how to encode prop224 onion addresses. Here is the latest thread: https://lists.torproject.org/pipermail/tor-dev/2016-December/011734.html Bikeshedding is over; it's time to finally pick a scheme! My suggested scheme basically follows from the discussion on that thread, and is heavily based on the Bitcoin address format: https://en.bitcoin.it/wiki/Base58Check_encoding https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addres… Here is the suggested scheme: onion_address = base32(version + pubkey + checksum) checksum = SHA3(".onion checksum" + version + pubkey) where: pubkey is 32 bytes (ed25519) version is one byte checksum is _truncated_ to two bytes With the above construction onion_address ends up being 56 bytes long (excluding the ".onion"): tbi5tdxbosiotphawjyu7f5pw5tlnvbvfjrj7meskbsnwr2bqbu2t4gg.onion tcrdnadkefvbdm3u56kz6lfh6v5lr24fpog5vzsy4n3djr2ymueu34ws.onion tcdw7lwmtp5pbwj2w7wf6amxdhmc62qitj2teu376r5s2fqke4r3uiq6.onion If people like the above suggestion, I will take the effort to engrave it in prop224. Here is the discussion section. Please provide feedback! [D1] How to use version field: The version field is one byte long. If we use it as an integer we can encode 256 values in it; if we use it as a bitmap we could encode properties and such. My suggestion is to simply use it as an integer like Bitcoin does. So we can assign value \x01 to normal onion services, and in the future we can assign more version tags if we need to. For example, we can give a different version field to onion services in the testnet. We can also reserve a range of values for application-specific purposes. [D1.1] Default version value: The next question is what version value to assign to normal onion services. In the above scheme where: onion_address = base32(version + pubkey + checksum) the value of 'version' basically determines the first two characters of the onion address. In Bitcoin, they've made it such that the default version value basically prefixes addresses with "1"; so all normal Bitcoin addresses start with 1 as in 14tDWDT9zqDufWZmiLqoaT9qJyHi7RRZPE What should we do in Tor? My suggestion is to use '\x98' as the default version value which prefixes all addresses with 't' (as in Tor). Check the examples I cited above. An alternative is to turn the scheme to: onion_address = base32(pubkey + checksum + version) where the version byte is at the end with no effect at usability. A heavier alternative would be to have two bytes of version so that we can just prefix them all with 'tor'... [D2] Checksum strength: In the suggested scheme we use a hash-based checksum of two bytes (16 bits). This means that in case of an address typo, we have 1/65536 probability to not detect the error (false negative). It also means that after 256 typos we will have 50% probability to miss an error (happy birthday!). I feel like the above numbers are pretty good given the small checksum size. The alternative would be to make the checksum four bytes (like in Bitcoin). This would _greatly_ increase the strength of our checksum but it would also increase our address length by 4 base32 characters (and also force us to remove leading padding from base32 output). This is how these 60-character addresses look like: tc2dty3zowj6oyhbyb5n3a2h3luztlx22hy2cwdvn37omsv7quy7rxiysn3a.onion tbdczrndtadzdhb6iyemnxf7f4i6x7yojnunarlrvt2virtmrecmwgx5golq.onion tc6pcgyorusw3jj5tosxakmcwfmcend2q4g2qnbjtkhuuh4dcgvs4rl4rdaa.onion You probably don't notice the size difference compared to the 56-character addresses, which perhaps is an argument for adopting a four byte checksum. Let me know what you think about this. [D3] Do we like base32??? In this proposal I suggest we keep the base32 encoding since we've been using it for a while; but this is the perfect time to switch if we feel the need to. For example, Bitcoin is using base58 which is much more compact than base32, and also has much better UX properties than base64: https://en.bitcoin.it/wiki/Base58Check_encoding#Background If we wanted to get a more compact encoding, we could adopt base58 or make our own adaptation of it. In this proposal I'm using base32 for everything, but I could be persuaded that now is the time to use a better encoding. Let me know what you think! Thanks :)

16 40

Pluggable Transports 2.0, draft 1 Specification
by Brandon Wiley 28 Mar '17

28 Mar '17

As was discussed in the Pluggable Transports session at TorDev Amsterdam, the Pluggable Transports 2.0, draft 1 specification [https://www. pluggabletransports.info/spec/pt2draft1] was created by a committee of censorship circumvention tool developers: Tor, Lantern, Psiphon, and uProxy. It specifies a version of Pluggable Transports that meets the needs of multiple circumvention tools. There is one major change that has implications for tor, which is that the Pluggable Transports 2.0, draft 1 IPC protocol uses a different type of SOCKS authentication mechanism, which allows for larger parameters to be send to transports. We are currently working on a 2nd draft of this specification, which will incorporate changes and errata from the community censorship circumvention tool community. For instance, syntactic errors in the documentation of the Go interface will be fixed in draft 2. Tor developers participated in the specification meetings, and now feedback from the overall Tor community is requested for incorporation in the next draft. There will also likely be a 2.1 specification process, possibility starting August, where we will consider larger changes.

2 4

GSOC 2017: Revised Proposal for anon-connection-wizard
by irykoon 27 Mar '17

27 Mar '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello everyone! I have revised my previous proposal with the help of anonym's feedback. Could anyone offer me some feedback about it please? Any recommendation, suggestion and criticism are very welcome and appreciate d! #####What project would you like to work on? I would like to work on the anon-connection-wizard. It is a Python-clone of the Tor Launcher which aims at providing Tor users with a graphical instruction on configuring the Tor. This [application](https://github.com/Whonix/anon-connection-wizard) has been developed as a part of the Whonix Project. Some of the screenshots of its old version can be found [here](https://www.whonix.org/blog/connection-bridge-wizard). This application is especially helpful for users who live in Tor-censored area. This is because those users can only connect to the Tor network with the help of other censorship circumvention tools which include but are not limited to Tor bridges, pluggable transports and other third party Internet censorship circumvention tools like Lantern and VPN. Currently, the Tor Launcher is shipped with the Tor Browser Bundle and heavily relies on the Tor Browser for its implementation. Although thanks to the great efforts([[1]](https://git-tails.immerda.ch/tails/tree/config/chroot_loca l-hooks/06-adduser_tor-launcher?h=devel), [[2]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/ 10-tbb?h=devel), [[3]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includ es/usr/local/sbin/tails-tor-launcher?h=devel), [[4]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includ es/usr/local/bin/tor-launcher?h=devel)) of Tails, the Tor Launcher can be run as a stand-alone XUL application currently, since the XUL will not be supported by mozilla in Firefox ESR branch [some time next year](https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/), that implementation may not work for a long time. Beiseds, I agree with the Whonix core developer Patrick Schleizer that "the Tor Browser Bundle has its kind of users. system Tor (refers to Tor from packages.debian.org or deb.torproject.org) users, where Tor runs as daemon, is used in different ways for different purposes". Therefore, although anon-connection-wizard is a Python-clone of the Tor luancher, since all its dependencies are already in Debian and already packaged, it can still serve as a really useful tool for the system Tor users or a loose coupling substituition to the Tor Launcher. In addition, the current instructions provided by the anon-connection-wizard and Tor launcher is not clear enough for users to configure Tor correctly. Therefore I would like to implement and redesign the anon-connection-wizard. I hope that my work will help more people to connect to the Tor network efficiently and successfully. #####Your proposal should also try to break down the project into tasks of a fairly fine granularity, and convince us you have a plan for finishing it. As mentioned above, my project goals include two main parts: ######The clone implementation of Tor Launcher: Currently, I have helped to implement the basic functions of anon-connection-wizard. However, there are still several bugs need fixing and a large number of exciting features need implementing, which include: 1. The current implementation of configuring torrc file is very rudimentary. The anon-connection-wizard should read the previous bridge/proxy configuration from the file and adjust the default UI accordingly. Just like what Tor Launcher has been doing. The ["edit marker approach"](https://forums.whonix.org/t/graphical-gui-whonix-setup-wizard - -anon-connection-wizard-technical-discussion/650/226) is preferred way to implement this; 2. The password for proxy setting should be covered by character *. ######The redesign of the anon-connection-wizard: I have made a specific [proposal](https://forums.whonix.org/t/a-proposal-for-redesigning-anon-c onnection-wizard-for-better-usability/3681) for this topic. And the redesign should at least includes: 1. Rearranging the instruction page orders for better usability; 2. Rewriting the literal instruction so that it fits the actual situation of people in censored areas; 3. Adding more features to the custom Tor bridges configuration input box for more clear instruction. For example, syntax highlight, tool-tips, etc; 4. Doing user behavior experiment to find out what can be helpful for better usability; 5. Modifying the anon-connection-wizard based on the result of the experiment. #####A timeline for what you will be doing throughout the summer is highly recommended. Since the specific dates may be changed with the undecided working schedule. I arrange my timeline in a week unit. Please notice that I have communicated with my potential mentor that we can work on some tasks in advanve if the project plan for a specific week is finished earlier than expected. | TIME | TODO | |------|------| |Week 1 | The password for proxy setting should be covered by character *.| |Week 3 | Rewrite the literal instruction so that it fits the actual situationy of people in censored areas.| |Week 4 | Generate ideas on redesigning the anon-continence-wizard users interface, basing on the recommendations from outside sources,problems discussed above and suggestions from other people. Present the planning redesign to public to receive feedback.| |Week 5 | Rearrange the instruction page orders for better usability; Rewriting the literal instruction so that it fits the actual situation of people in censored areas.| |Week 6 | Add more features to the custom Tor bridges configuration input box for more clear instruction. For example, syntax highlight, tool-tips, etc.| |Week 7 | Prepare for the user behavior experiment, including recruitment and setting up environment.| |Week 8 | Conduct the experiment.| |Week 9 | Process and analysis the experiment data.| |Week 10| Write the research report.| |Week 11| Modify the anon-connection-wizard based on the result of the experiment.| |Week 12| Modify the anon-connection-wizard based on the result of the experiment.| #####Point us to a code sample: something good and clean to demonstrate that you know what you're doing, ideally from an existing project. The followings are a part of my pull requests to the anon-connection-wizard project on GitHub: 1. [Basic features implementation](https://github.com/Whonix/anon-connection-wizard/pull/1) ; 2. [Pluggable transport renew](https://github.com/Whonix/anon-connection-wizard/pull/2); 3. [Port from Python2 to Python3.4 & from PyQt4 to PyQt5](https://github.com/Whonix/anon-connection-wizard/pull/4). The following is my proposal for the redesign of anon-connection-wizard in Whonix Forum: 1. [A proposal for redesigning anon-connection-wizard for better usability](https://forums.whonix.org/t/a-proposal-for-redesigning-anon-c onnection-wizard-for-better-usability/3681) #####Why do you want to work with The Tor Project in particular? As one who was living in oppressive area, I deeply understand the importance of Internet freedom to a society. At first, I merely considered Internet freedom as fighting against Internet censorship. However, after a large amount of observation, reading and reflection, I realized that the self-censorship conducted by every scared citizens was much more powerful and terrible than the censorship conducted by the outside world. It was at that moment I realized the online anonymity was a vital component to Internet freedom because it frees people from fear. I value Tor/Whonix. Without it, I couldn't have been freed from the fear and explored the world freely and finally became who I am today. Therefore, contributing to Tor/Whonix as a career is not only a dream that I have been fighting for, but also an essential approach to my self-actualization. #####Tell us about your experiences in free software development environments. We especially want to hear examples of how you have collaborated with others rather than just working on a project by yourself. I agree that “[o]pen and clear communication is of utmost importance”. This is because of two main reasons from my point of view. First, a successful free and open source software development heavily relies on the collaboration between different people. A good communication skill will create a positive and supportive atmosphere which not only make everyone works for it more efficient but also attracts more people to join the development. Second, feedback from others, especially mentor, can be extremely beneficial to a student’s progress. Without the feedback, it may take a student years until one day after a frustrating debugging process to realize a mistake he/she made; while he/she may realize several mistakes he/she made almost immediately from his/her mentor’s feedback. I have already been working on the project with my potential mentor Patrick Schleizer. A small part of our open communication can be found [here](https://forums.whonix.org/t/graphical-gui-whonix-setup-wizard-ano n-connection-wizard-technical-discussion/650/222), which may be helpful to prove we have been having an open and clear communication. I also take Jean-Philippe Ouellet's words said on the Qubes-devel mailing list as an encouragement to me: > This kind of detailed and engaged communication is a model to all GSoC applicants #####Will you be working full-time on the project for the summer, or will you have other commitments too (a second job, classes, etc)? If you won't be available full-time, please explain, and list timing if you know them for other major deadlines (e.g. exams). Having other activities isn't a deal-breaker, but we don't want to be surprised. I am going to be enrolled for the Summer 2017 semester that begins May 22nd and ends June 23th at XXX University. I am going to take two classes from Monday to Friday for each week during the Summer semester. One will be from 3:20PM to 5:00PM (UTC) and another one will be from 7:00PM to 8:40PM (UTC). The sum of the time I will be in class for each weekday will be 3 hours and 20 minute which is totally fine to me. My current overall GPA is 4.0/4.0 which may help to prove I can handle my school study well. According to Google Summer of Code timeline, the “[c]oding officially begins” at May 30th which means there will be approximate three weeks that I have both school study and Google Summer of Code. To work around it, I have came up with three plans which either of them is fine to my potential mentor: 1. Since I have been familiar with the contributing workflow for Whonix, I do not have to spend a lot of time to get used to it. Therefore I can use the “Community Bonding Period” which is from May 4th to May 30th to do the real coding for the project; 2. I can also keep committing to the project during each weekend from now on before May 4th . This is also a way to work around the time conflicts. 3. If I am expected to code only during the official timeline, I can spend 5 hours each day during the weekdays and spend 8 hours each day during the weekends. #####Will your project need more work and/or maintenance after the summer ends? Yes! Tails developer anonym pointed out a promising future for the anon-connection-wizard on the tor-dev mailing list: > "I also see potential for future collaboration between Whonix and Tails for extending the usefulness of anon-connection-wizard beyond what Tor Launcher (and its replacement) offers [2]; anon-connection-wizard targets the OS, not just a single application, so it could integrate the choices of network configuration (wired? which wireless network? MAC spoofing?) and Tor configuration (proxy? pluggable transport?) in a single place which probably makes more sense for users and also allows us to more easily (optionally) save these settings so they are restored the next time you visit the same network. This could potentially even be used to help giving users control over entry node selection to avoid persistent Entry Guards from leaking information about you geographical movement. [3]" #####What are the chances you will stick around and help out with that and other related projects? Since I would like to take contributing to Tor/Whonix as a career, I will definitely stick around the Tor/Whonix community and help out with the future development of my project and other related ones. I never consider my project as a one-time project. Instead, I consider it as an important step to help myself get more invovled in the Tor/Whonix community. #####What is your ideal approach to keeping everybody informed of your progress, problems, and questions over the course of the project? Said another way, how much of a "manager" will you need your mentor to be? My plan is to take the [Whonix Forum](https://forums.whonix.org/) as the daily communication platform with my potential mentor Patrick. And just like what I have been doing, I will also post a detailed progress report for each working period which is no more than a week. Since the anon-connection-wizard is hosted on Github right now, people can also take it as a way to see my commits and progress. I can also send the posts to the tor-dev mailing list if it is considered as a good idea. #####What school are you attending? What year are you, and what's your major/degree/focus? If you're part of a research group, which one? If these information is necessary, please do not hesitate to contact me. My contact information is listed in the next section. #####How can we contact you to ask you further questions? Currently, people can contact me through the following ways: 1. Email: irykoon at gmail dot com [GPG](https://pgp.mit.edu/pks/lookup?op=vindex&search=0xA14B4DBC6DCDD53C ) 2. Github: @irykoon 3. Whonix Forum: @iry I will inform the public if there is any change to my contact informatio n. #####Are you applying to other projects for GSoC and, if so, what would be your preference if you're accepted to both? Having a stated preference helps with the deduplication process and will not impact if we accept your application or not. I am going to submit the same proposal to both the Tor Project and the Qubes Project. This is because I would like to avoid the situiation where one of the projects does not get as many slots as it wants from google. I will be extremly happy to be accepted by either of the projects. Since my project may benifit the Tor Project more, I would prefer it when I am accepted by both of the projects. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY2UGjAAoJEKFLTbxtzdU8coMQAIsfxRw5Fdyrnwp6Rb13zpEh ugDr9FdDOuIMmIQbEKn+kXoYUoECuuDXa0r+DLOS9HodPJ6MrksDr8956HsusEnw 7XyJLlfL+pccNPzsyXe+O5UgiMYlmIJpH4+7tHyZ0bYkjzrxsa6TPaP/iODoby3d B2f5GUXgt5X1vpGBmGGVpOzTYTSJwnNaFfpE4O6dCm41aMsuMsIGj1vRH80SqrsT XJKBdgEKbwewGEwLNgdMx5XlH+9rARv0Ytx83GI8894sx80Rl2S9wL9D5km7IoWW n3+8HS0wzFOkCIFPumfAtwAHtJRTyWVEc4jr/waObPwJtK/cnoOwkVHXbimvnWoc dr7qjNBDDms98rXDD6gxgKToIKgdgDJetMW9QWhDBTXuZcbq6bwmONoTZ94/4mR6 V0E2HhGkjF/RLCu8dP+oHVPdEsFN1er/l9SEUreqF78+VRFwspAc7y5nIo/0WXDV t/zKeiqYjsw+bHC7Dbaxax67QXNuWe3viToCYtPOKGMat7ORlTj+eqNaE6iRt+q/ N91Wd/B86v5ibWy9UEN4Uo/FqwT+YOjOYJ1yoXZRmnrdwhYalAt3ESCqCi3cMDc8 eRQGbtCwGeaGd5g03OfBe8zQwswj11yTwi1xsIOL/RdVXt7Af6Q1MMd6a0g0Rub0 6WV1NX+Knl88tbzyRpQ5 =ioNx -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] GSOC 2017: Proposal for anon-connection-wizard (anonym)
by irykoon 27 Mar '17

27 Mar '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 anonym: > I might be misunderstanding what you and Patrick mean with > "impossible" (or rather, which use cases are impossible) w.r.t. > using Tor Launcher outside of the Tor Browser; Tails uses the Tor > Launcher shipped in Tor Browser, but it's run as a stand-alone XUL > application (`firefox --app ...`), so the *web* browser isn't > started as part of it. [1] One could even run it using > Iceweasel/Firefox, i.e. completely without Tor Browser. > Thank you very much for your explaination, anonym! I did find my words misleading here. I have corrected my mistakes. How do you like this one: " Currently, the Tor Launcher is shipped with the Tor Browser Bundle and heavily relies on the Tor Browser for its implementation. Although thanks to the great efforts([[1]](https://git-tails.immerda.ch/tails/tree/config/chroot_loca l-hooks/06-adduser_tor-launcher?h=devel), [[2]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/ 10-tbb?h=devel), [[3]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includ es/usr/local/sbin/tails-tor-launcher?h=devel), [[4]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includ es/usr/local/bin/tor-launcher?h=devel)) of Tails, the Tor Launcher can be run as a stand-alone XUL application currently, since the XUL will not be supported by mozilla in Firefox ESR branch [some time next year](https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/), that implementation may not work for a long time. Beiseds, I agree with the Whonix core developer Patrick Schleizer that "the Tor Browser Bundle has its kind of users. system Tor (refers to Tor from packages.debian.org or deb.torproject.org) users, where Tor runs as daemon, is used in different ways for different purposes". Therefore, although anon-connection-wizard is a Python-clone of the Tor luancher, since all its dependencies are already in Debian and already packaged, it can still serve as a really useful tool for the system Tor users or a loose coupling substituition to the Tor Launcher. " > That said, this approach will not be viable any more some time next > year when the Firefox ESR branch drops XUL support and Tor > Launcher is deprecated upstream. Thank you so much for pointing out the fact. It makes the anon-connection-wizard project even more meaningful and helpful because it may serve as a substitution to the Tor Launcher in the future. I have add the point to my proposal! > It remains to see how the replacement of Tor Launcher will look, > it might still work for Tails. However, if anon-connection-wizard > would be a (more or less) drop-in replacement for Tor Launcher in > Tails, that would be immensely helpful since we'd have a solution > that will be guaranteed to work for us without much work. I am really glad to hear that my project may potentially be helpful to Tails. If this can happen one day in the future, it can benifit even more Tor users. > And I guess as long as the UX is more or less identical to the new > Tor Launcher and rapidly adapts to changes, and there are good > translations, we'd probably prefer it over the new Tor Launcher, > since it probably will be even harder to decouple from the web > browser. The UX is a main part of the anon-connection-wizard proposal. During the summer, I will mainly focus on the improvement of verbal instructions and the user interface instructions in anon-connection-wizard. Patrick has helped me to get the latest paper by Linda on tor-launcher usability, so that I can redesign the anon-connection-wizard basing on some solid research findings. Please look forward to it :) I am not worried too much about the translation actually. If the anon-connection-wizard is good and useful enough, maybe I can turn to the Tor Project translation [team](https://www.transifex.com/otf/torproject/) for help. The team is very efficient and active. BTW could you please tell me where I can find more about the development progress of the new Tor Launcher? I believe some communication and collaboration between us will be benefitial to both the anon-connection-wizard and the new Tor Launcher. Thank you very much! > > Any way, I also see potential for future collaboration between > Whonix and Tails for extending the usefulness of > anon-connection-wizard beyond what Tor Launcher (and its > replacement) offers [2]; This can be a really good point! If you don't mind, I would like to quote your idea as the "future work" in my proposal. > anon-connection-wizard targets the OS, not just a single > application, so it could integrate the choices of network > configuration (wired? which wireless network? MAC spoofing?) I agree with you that: > "save these settings so they are restored the next time you visit > the same network. This could potentially even be used to help > giving users control over entry node selection to avoid persistent > Entry Guards from leaking information about you geographical > movement." However, I am not sure if integrating the system-network-setting-related configuration(like MAC spoofing) in anon-connection-wizard will be a good idea in terms of a low coupling design. I am probably wrong but I personally prefer considering the anon-connection-wizard only as an graphical application to configure Tor, specifically, to configure torrc file. Could you please share your insights about how we should define the anon-conncetion-wizard please? I am really looking forward to hearing your thoughts. > and Tor configuration (proxy? pluggable transport?) in a single > place which probably makes more sense for users Yes! Let's brainstorm more about the [torrc-related setting](https://www.torproject.org/docs/tor-manual.html.en) at least! How about the FascistFirewall setting?! Users who are not really live in Tor-censored area should avoid using Tor Bridges for better anonymity. > > Cheers! > > [1] The first two scripts are parts of the build process, the two > latter ones are for starting it: * > https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/06-a dduser_tor-launcher?h=devel > > > > * https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/10-tbb ?h=devel > * > https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/u sr/local/sbin/tails-tor-launcher?h=devel > > > > * https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/usr /local/bin/tor-launcher?h=devel > [2] https://tails.boum.org/blueprint/network_connection/ [3] We > discuss the issue of > https://tails.boum.org/blueprint/persistent_Tor_state/ Thank you so much for your helpful sources. I will look at them in detail soon! Please let me say thank you again for your feedback, anonym! I really appreciate your help! I have revised my proposal with the help of your feedback and I am going to send it to tor-dev mailing list in a seperate email! Please look forward to it! -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY2TTWAAoJEKFLTbxtzdU88AsP/0cCPcMrTt2lOtF21jrrZV8Q sEPfYRWfsDc1Yc5QT+9zlOLynw7+W9BJ/WwwytCk37YmxS/xvl2T2/mGkoLH0hhk G4kJ58HyNmnjEA8fYnT77QWvh96Uznz7jeOd0th/tg9aZVcbFur7YBMSRnNzpMGq leqtiYNtd/HmVXHAGkAhy7GvMOHrfaEQiRXCSUuAJ6NR6W2cagELVfurEdZw7KkO 2OvHbe61oFS5p4n5ILdg+OLmXevpFtUA8YsbIxttIiaBhwkBNlMFUr/5Z9JY53v3 Q6ueYEaxKzFXwiaicWfhVgEGuDl4Ez5a7bTEvXATcXN0AldTNou8MBeontca728B lmh4wEGb/WM8ktnq/87kQD4oHkSUomGhati09kw70dCdkQhI5KmQM/3RwLrm/KNV XKuA/eeOHyV1E+1uh5GCODNKfbDSNR9k+M2wSiXFsrDb+9tcczP4MND/moiziquU 4TvK8mM6cFy0d3hO2QFIaL3myIRdu/+MvLZxMOnsqUb0KegBnmhgBePq/Txuxyb5 9pKvO0Oy4cDsLwx/LAR/YBmJbvLVuyyK+2woB94o39UsZYwJqBw9/VBfhUND2Iyh w0c0CvsRjyXo1v/EySE9W4wnpCWc7YHaFL9luYTyzQiCJyXrCFYt6JIiyEYZ6dQw MXWPr7sds1a8YMYlGh/1 =QjbB -----END PGP SIGNATURE-----

1 0

The behavior of ClientRejectInternalAddresses
by Jesse V 26 Mar '17

26 Mar '17

Hi everyone, I would like some clarification on ClientRejectInternalAddresses. The manual says: > "If true, Tor does not try to fulfill requests to connect to an internal address (like 127.0.0.1 or 192.168.0.1) unless a exit node is specifically requested (for example, via a .exit hostname, or a controller request). (Default: 1) In other words, if I disable this flag and I open 127.0.0.1:8080 in the Tor Browser, will the browser or the tor binary attempt to connect to the client's 127.0.0.1:8080? This is essentially what I'm after, and I just want to confirm that ClientRejectInternalAddresses is the best approach, or if there is a better setting. Just to clarify, I want to connect the client's localhost and not an exit's. -- Jesse

2 1

One Valid Next-Generation Onion Address per Private Key
by teor 26 Mar '17

26 Mar '17

Hi all, Most onion service users expect that there is only one valid onion address for their private key. (For example, one address is listed in SSL certificates.) I spoke with Ian, and he said that as part of validating the onion address, we should check if it is a valid point. He said we need to multiply the point by L, and make sure there's no torsion component (that is, that the result is the identity). This avoids the complexity of choosing a canonical point using some lexicographic order, or the complexity of using something like decaf. (Hopefully, Ian will write back if I transcribed things incorrectly.) T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

2 1

Re: [tor-dev] french documentation
by teor 26 Mar '17

26 Mar '17

> On 26 Mar 2017, at 20:58, Thierry Boibary <th.boibary(a)net-c.com> wrote: > > hi, > i'd like to collaborate to Tor, in the hidden services for example Tor2web, Torbirdy, metrics portal ..... Here is some information about these projects: https://www.torproject.org/getinvolved/volunteer.html.en Sorry, it is only in English. Tim > regards > > T Boibary > 06 85 55 34 89 > > <1481836001.1313601483.0> > > > ---- Message d'origine ---- > De : teor <teor2345(a)gmail.com> > À : tor-dev(a)lists.torproject.org > Objet : Re: [tor-dev] french documentation > Date : 24/03/2017 09:24:18 CET > Copie à : Thierry Boibary <th.boibary(a)net-c.com> > > > > On 11 Feb 2017, at 07:55, Thierry Boibary <th.boibary(a)net-c.com> wrote: > > > > hi, > > where can i find french documentation? > > i am expert in systems and networks administration so i'd like working for you, in a domain which needs my capabilities. > > > > help me to find a domain? please > > > > Regards > > T > > Hi Thierry, > > Sorry it has taken a long time for me to reply. > > We have Tor Browser in French: > https://www.torproject.org/projects/torbrowser.html.en#downloads > > We want other documentation in French, but we need people to help! > > What documentation do you want? > > T > > -- > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > ------------------------------------------------------------------------ > > T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0

french documentation
by Thierry Boibary 24 Mar '17

24 Mar '17

hi, where can i find french documentation? i am expert in systems and networks administration so i'd like working for you, in a domain which needs my capabilities. help me to find a domain? please Regards T T Boibary 06 85 55 34 89

2 1