Re: [tor-talk] Tor Speculated Broken by FBI Etc - Freedom Hosting, MITTechReview - Magneto
Hi everybody Am 2020-02-09 um 12:40 PM schrieb grarpamp: Given the variety of known weaknesses, exploits, categories of papers, and increasing research efforts against tor and overlay networks in general, and the large number of these "mystery gaps" type of articles (some court cases leaving hardly any other conclusion with fishy case secrecy, dismissals, etc)... the area of speculative brokeness and parallel construction seems to deserve serious investigative fact finding project of global case collation, interview, analysis to better characterize. ... Early on August 2 or 3, 2013, some of the users noticed “unknown Javascript” hidden in websites running on Freedom Hosting. Hours later, as panicked chatter about the new code began to spread, the sites all went down simultaneously. The code had attacked a Firefox vulnerability that could target and unmask Tor users—even those using it for legal purposes such as visiting Tor Mail—if they failed to update their software fast enough. While in control of Freedom Hosting, the agency then used malware that probably touched thousands of computers. The ACLU criticized the FBI for indiscriminately using the code like a “grenade.” The FBI had found a way to break Tor’s anonymity protections, but the technical details of how it happened remain a mystery. https://www.wired.com/threatlevel/2013/09/freedom-hosting-fbi/ A malicious route around Tor was/is solvable by keeping the system updated or by the use of techniques like Whonix or Tails. -- Cheers, Felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] German court drains traffic data retention law
Should be the highest court in this case. space.net did it. Good for freedom of internet and communication. https:// www.heise.de/newsticker/meldung/Oberverwaltungsgericht-Vorratsdatenspeicherung-ist-europarechtswidrig-3753179.html 10 days were left - so right in time :) -- Cheers, Felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Manual Update of Tor-Network-Components in Tor-Browser
Hello, I use an older Version of Tor-Browser on an old Linux-machine. Tor seems to use a list of "initial Tor-Nodes to contact" when I establish a connection to the Tor-Network (i.e. turtles.fscked.org). Some entries in this list (i.e. the IP-Adresse 212.112.245.170) seem not to be valid anymore and cannot be contacted. Is it possible to update this list without updating the Tor-Browser-Package? Or ist this Node (212.112.245.170) still valid and do I have a Network-Problem? Thanks, regards Felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Manual Update of Tor-Network-Components in Tor-Browser
Hello, I use an older Version of Tor-Browser on an old Linux-machine. Tor seems to use a list of "initial Tor-Nodes to contact" when I establish a connection to the Tor-Network (i.e. turtles.fscked.org). Some entries in this list (i.e. the IP-Adresse 212.112.245.170) seem not to be valid anymore and cannot be contacted. Is it possible to update this list without updating the Tor-Browser-Package? Or ist this Node (212.112.245.170) still valid and do I have a Network-Problem? Thanks, regards Felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How can I verify that this "Onionshare" program is indeed the one intended for me to get?
Hey. Am 15.11.2015 11:28, schrieb Qaz: How do I do the hashing? Sorry really ignorant about it. Do I just type sha256sum ? Or what? Hashing the deb is most likely not going to work. Having a build process that results in a bit-wise identical binary is a hard problem (search for "reproducible build" if you're interested). You should use the verification tools provided, that is the detached signature for pre-built binaries and the signed commits when building from source (see my other mail). Regards felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How can I verify that this "Onionshare" program is indeed the one intended for me to get?
Hi. Am 14.11.2015 15:00, schrieb Qaz: If you guys don't mind, could someone tell me how I can verify that this Onionshare program is indeed the one intended for me to get? I haven't seen anything or instructions like verification unlike on Macs and Windows. https://github.com/micahflee/onionshare/blob/master/BUILD.md#gnulinux The release tags for onionshare in Git are signed, so to verify the current version use: $ git tag --verify 0.7.1 If you are happy with the result, checkout the release $ git checkout 0.7.1 and then continue with building your package. Regards felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Question Regarding Routing of Network-Traffic using Tor-Browser
Hello, I read the linked Page and understand most of the ideas behind the concept of using only a few number of Entry-Guadrs. However, as I understand Entry Guards are chosen by Parameters like Response-Time or Network-Bandwidth. If i.e North Corea. would like to control the Tor-Network in NC, NC would have to do the following things: 1. Slow down (or disable) the rest of the Internet from outside NC extremely. 2. Setup some fast Tor-Servers (Primary Entry Guards) inside NC. 3. Provide fast Tor-Relays (inside NC) that are accessible from these Entry Guards (other Tor-Relays are slow from or inaccessible these Entry Guards) 4. Provide (fast) Exit-Nodes inside NC. In this scenario the fast Primary Entry Guards would proably the chosen for almost any Network-Traffic using Tor, and I could at least see which IP-Source-Adresse would bei using Tor. If the rest of the Tor-Network would rely on Performance-Data for Routing the Traffic, NC could proably also see the Tor-Relays (and maybe even the Exit-Nodes) - so Tor would be (somehow) useless. So in my opinion it would be at least a good (configurable) option to provide dynamic switching of the Entry-Guards - as this would at least make it more difficult to trace every move of a Tor-User. Regards, Felix Am 01.11.2015 02:24, schrieb Harmony: Felix: Hello, I am from Germany and I use the Tor-Browser very often. I think Tor is a great product. I have a question regarding the connection from my Tor-Browser to the Tor-Network. I noticed, that Tor tends to always connect to the same Tor-Relays on the internet. I can observe this when I monitor the connections using Netstat on my Linux-machine - even after restart of the Tor-Browser or even after a reboot of the Linux-machine. So my initial Idea was to delete the "cached*-files" in the /Data/Tor-Directory before each start - but this does not help - Tor always connects basically to the same Tor-Nodes all the time. I think this is probably due to an internal "ranking" in the Tor-Network. So my question is, would´nt it be better (or more secure) for the End-User, if the Tor-Browser (or the Onion-Router) would change the used Tor-Relays i.e. every 5 minutes. As the Tor-Browser connects to more than one Tor-Relay, this could be staged, Drop Tor-Relay 1 after connection to Tor-Relay 3 has been established i.e. Are there any plans to enhance the Tor-Network / the Tor-Browser in this direction? Hello Felix, https://www.torproject.org/docs/faq#EntryGuards This is in fact a safety mechanism that Tor uses, as explained in the above link. If your browser connected to new 'first-hop' relays every time, there would be a greater chance that one day all the relays in your circuit are attacking you. By picking one (or a few) guards only and cycling them rarely, it is that much more tedious for anyone who is waiting until you pick their bad relay in order to attack you. Tor certainly did at one stage change its circuits after ten minutes, as you suggest, but for various reasons this was altered, and in any case Tor Browser itself manages circuits in a different way to the core Tor program. It's a much-discussed question and no one yet has the perfect answer. If for some reason you really do need to change the guards that your browser is using, the file to delete is called 'state', and it is under Browser/TorBrowser/Data/Tor (on Linux). Generally, however, you should not do that. [I am not an expert on any of the above.] Thanks, Thank you very much. Regards, Felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Question Regarding Routing of Network-Traffic using Tor-Browser
O.K., I found a workaround, I edited the File start-tor_browser and inserted a command at the beginning, that deletes the State-File in /Data/Tor. Thank you, Harmony... Am 01.11.2015 11:12, schrieb Tom van der Woerdt: > Felix, > > Guards' network speeds are assessed based on the view of the network, not the > client. What this means for your North Korea example is that the government > couldn't affect path selection by slowing down the network, as Tor will still > pick the same guards. > > Tom > > >> On 01 Nov 2015, at 11:10, Felix <felix.wiedenr...@gmx.de> wrote: >> >> Hello, >> >> I read the linked Page and understand most of the ideas behind the concept >> of using only a few number of Entry-Guadrs. However, as I understand Entry >> Guards are chosen by Parameters like Response-Time or Network-Bandwidth. >> >> If i.e North Corea. would like to control the Tor-Network in NC, NC would >> have to do the following things: >> >> 1. Slow down (or disable) the rest of the Internet from outside NC extremely. >> 2. Setup some fast Tor-Servers (Primary Entry Guards) inside NC. >> 3. Provide fast Tor-Relays (inside NC) that are accessible from these Entry >> Guards (other Tor-Relays are slow from or inaccessible these Entry Guards) >> 4. Provide (fast) Exit-Nodes inside NC. >> >> In this scenario the fast Primary Entry Guards would proably the chosen for >> almost any Network-Traffic using Tor, and I could at least see which >> IP-Source-Adresse would bei using Tor. >> >> If the rest of the Tor-Network would rely on Performance-Data for Routing >> the Traffic, NC could proably also see the Tor-Relays (and maybe even the >> Exit-Nodes) - so Tor would be (somehow) useless. >> >> So in my opinion it would be at least a good (configurable) option to >> provide dynamic switching of the Entry-Guards - as this would at least make >> it more difficult to trace every move of a Tor-User. >> >> Regards, >> >> Felix >> >> >> >> Am 01.11.2015 02:24, schrieb Harmony: >>> Felix: >>>> Hello, >>>> >>>> I am from Germany and I use the Tor-Browser very often. I think Tor is a >>>> great product. >>>> >>>> I have a question regarding the connection from my Tor-Browser to the >>>> Tor-Network. >>>> >>>> I noticed, that Tor tends to always connect to the same Tor-Relays on >>>> the internet. I can observe this when I monitor the connections using >>>> Netstat on my Linux-machine - even after restart of the Tor-Browser or >>>> even after a reboot of the Linux-machine. >>>> >>>> So my initial Idea was to delete the "cached*-files" in the >>>> /Data/Tor-Directory before each start - but this does not help - Tor >>>> always connects basically to the same Tor-Nodes all the time. I think >>>> this is probably due to an internal "ranking" in the Tor-Network. >>>> >>>> So my question is, would´nt it be better (or more secure) for the >>>> End-User, if the Tor-Browser (or the Onion-Router) would change the used >>>> Tor-Relays i.e. every 5 minutes. As the Tor-Browser connects to more >>>> than one Tor-Relay, this could be staged, Drop Tor-Relay 1 after >>>> connection to Tor-Relay 3 has been established i.e. >>>> >>>> Are there any plans to enhance the Tor-Network / the Tor-Browser in this >>>> direction? >>> Hello Felix, >>> >>> https://www.torproject.org/docs/faq#EntryGuards >>> >>> This is in fact a safety mechanism that Tor uses, as explained in the >>> above link. If your browser connected to new 'first-hop' relays every >>> time, there would be a greater chance that one day all the relays in >>> your circuit are attacking you. By picking one (or a few) guards only >>> and cycling them rarely, it is that much more tedious for anyone who is >>> waiting until you pick their bad relay in order to attack you. >>> >>> Tor certainly did at one stage change its circuits after ten minutes, as >>> you suggest, but for various reasons this was altered, and in any case >>> Tor Browser itself manages circuits in a different way to the core Tor >>> program. It's a much-discussed question and no one yet has the perfect >>> answer. >>> >>> If for some reason you really do need to change the guards that your >>> browser is using, the file to delete is called 'state', and it is under >>> Browser/TorBrowser/Data/Tor (on Linux). Generally, however, you should >>> not do that. >>> >>> [I am not an expert on any of the above.] >>> >>> Thanks, >>> >>>> Thank you very much. >>>> >>>> Regards, >>>> >>>> Felix >> -- >> tor-talk mailing list - tor-talk@lists.torproject.org >> To unsubscribe or change other settings go to >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Question Regarding Routing of Network-Traffic using Tor-Browser
O.K., so if the Guards that are used are based on the view of the network, this means NC knows which Entry-Guards are accessed from users within NC, so the next approach would be to fake these Entry-Guards (IPs) from within the country (Lets setup a Tor-Node inside NC, that uses the same IP as the Tor-Node that would be accessed from outside NC)... Isn´t Kim Jong-UN a smart guy somehow? ;-) Am 01.11.2015 11:12, schrieb Tom van der Woerdt: > Felix, > > Guards' network speeds are assessed based on the view of the network, not the > client. What this means for your North Korea example is that the government > couldn't affect path selection by slowing down the network, as Tor will still > pick the same guards. > > Tom > > >> On 01 Nov 2015, at 11:10, Felix <felix.wiedenr...@gmx.de> wrote: >> >> Hello, >> >> I read the linked Page and understand most of the ideas behind the concept >> of using only a few number of Entry-Guadrs. However, as I understand Entry >> Guards are chosen by Parameters like Response-Time or Network-Bandwidth. >> >> If i.e North Corea. would like to control the Tor-Network in NC, NC would >> have to do the following things: >> >> 1. Slow down (or disable) the rest of the Internet from outside NC extremely. >> 2. Setup some fast Tor-Servers (Primary Entry Guards) inside NC. >> 3. Provide fast Tor-Relays (inside NC) that are accessible from these Entry >> Guards (other Tor-Relays are slow from or inaccessible these Entry Guards) >> 4. Provide (fast) Exit-Nodes inside NC. >> >> In this scenario the fast Primary Entry Guards would proably the chosen for >> almost any Network-Traffic using Tor, and I could at least see which >> IP-Source-Adresse would bei using Tor. >> >> If the rest of the Tor-Network would rely on Performance-Data for Routing >> the Traffic, NC could proably also see the Tor-Relays (and maybe even the >> Exit-Nodes) - so Tor would be (somehow) useless. >> >> So in my opinion it would be at least a good (configurable) option to >> provide dynamic switching of the Entry-Guards - as this would at least make >> it more difficult to trace every move of a Tor-User. >> >> Regards, >> >> Felix >> >> >> >> Am 01.11.2015 02:24, schrieb Harmony: >>> Felix: >>>> Hello, >>>> >>>> I am from Germany and I use the Tor-Browser very often. I think Tor is a >>>> great product. >>>> >>>> I have a question regarding the connection from my Tor-Browser to the >>>> Tor-Network. >>>> >>>> I noticed, that Tor tends to always connect to the same Tor-Relays on >>>> the internet. I can observe this when I monitor the connections using >>>> Netstat on my Linux-machine - even after restart of the Tor-Browser or >>>> even after a reboot of the Linux-machine. >>>> >>>> So my initial Idea was to delete the "cached*-files" in the >>>> /Data/Tor-Directory before each start - but this does not help - Tor >>>> always connects basically to the same Tor-Nodes all the time. I think >>>> this is probably due to an internal "ranking" in the Tor-Network. >>>> >>>> So my question is, would´nt it be better (or more secure) for the >>>> End-User, if the Tor-Browser (or the Onion-Router) would change the used >>>> Tor-Relays i.e. every 5 minutes. As the Tor-Browser connects to more >>>> than one Tor-Relay, this could be staged, Drop Tor-Relay 1 after >>>> connection to Tor-Relay 3 has been established i.e. >>>> >>>> Are there any plans to enhance the Tor-Network / the Tor-Browser in this >>>> direction? >>> Hello Felix, >>> >>> https://www.torproject.org/docs/faq#EntryGuards >>> >>> This is in fact a safety mechanism that Tor uses, as explained in the >>> above link. If your browser connected to new 'first-hop' relays every >>> time, there would be a greater chance that one day all the relays in >>> your circuit are attacking you. By picking one (or a few) guards only >>> and cycling them rarely, it is that much more tedious for anyone who is >>> waiting until you pick their bad relay in order to attack you. >>> >>> Tor certainly did at one stage change its circuits after ten minutes, as >>> you suggest, but for various reasons this was altered, and in any case >>> Tor Browser itself manages circuits in a different way to the core Tor >>> program. It's a much-discussed question and no one
[tor-talk] Question Regarding Routing of Network-Traffic using Tor-Browser
Hello, I am from Germany and I use the Tor-Browser very often. I think Tor is a great product. I have a question regarding the connection from my Tor-Browser to the Tor-Network. I noticed, that Tor tends to always connect to the same Tor-Relays on the internet. I can observe this when I monitor the connections using Netstat on my Linux-machine - even after restart of the Tor-Browser or even after a reboot of the Linux-machine. So my initial Idea was to delete the "cached*-files" in the /Data/Tor-Directory before each start - but this does not help - Tor always connects basically to the same Tor-Nodes all the time. I think this is probably due to an internal "ranking" in the Tor-Network. So my question is, would´nt it be better (or more secure) for the End-User, if the Tor-Browser (or the Onion-Router) would change the used Tor-Relays i.e. every 5 minutes. As the Tor-Browser connects to more than one Tor-Relay, this could be staged, Drop Tor-Relay 1 after connection to Tor-Relay 3 has been established i.e. Are there any plans to enhance the Tor-Network / the Tor-Browser in this direction? Thank you very much. Regards, Felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TIMB vs TextSecure
Ted, Am 01.03.2014 19:12, schrieb Ted Smith: For text messaging, anonymity in the Tor sense doesn't make sense. Phone numbers are the only identifier you have for obvious reasons. not really. There are plans for a desktop client with email as identifier. Also, opting out of out-discovery of contacts (i.e. sending your whole address book to the push server) is both planned and necessary. Other than that I agree - the Tor use-case is a different one. felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TIMB vs TextSecure
Hey. Am 01.03.2014 08:23, schrieb Gordon Morehouse: With the news hitting some tech sites about TIMB, I went digging around briefly to find the reasoning for rolling something anew rather than backing e.g. TextSecure. (I know there are serious questions about the security of Telegram.) I'm sure there is a good reason, but what is it? Using Tor gives you a few properties that no other instant messaging solution can currently provide. - The IM server can not learn your IP. - A network observer can not learn that you are using IM (just that you are using Tor). - You cannot block the IM service without blocking Tor. Furthermore, there are (in my opinion) still some serious problems with TextSecure, most importantly: - Only phone numbers as identifiers. - Sends your address book to the server in full (hashed, but that doesn't mean anything for phone numbers). No opt-out if you want to use the push transport. - Requires Google Play to be installed and uses GCM for notifications. Though moxie has plans to address these problems, they currently exist. felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Using HTTPS Everywhere to redirect to .onion
Hey. Am 27.02.2014 00:27, schrieb fortasse: My question is does this have more potential than being a weird (rather effective) hack? Could we make an onion Everywhere as it were to help solve the difficult-to-remember onion names? Or is this just another layer of confusion that further increases the barrier of entry on successful Tor use? That seems like a dangerous idea. Anyone could easily set up a transparent proxy behind a .onion domain. If I can convince your project to include that .onion (which sounds easy given that most site owners will not know about it) I now have active MITM capability against anyone using that extension. You would have to make it very clear that it is a censorship-resistance tool, not a privacy tool. felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Verifying node operator identity (was: New paper : Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries)
Joe, Am 17.10.2013 02:42, schrieb Joe Btfsplk: What about somehow getting a better handle on who actually runs the nodes? tried very hard to find any suggestion on how this might work in your mail to no avail. Are you actually suggesting extensive personal interviews, background checks, giving polygraph tests, injecting sodium pentathol to those wanting to run nodes and expect some form of serious feedback? felix -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
