[tor-relays] Information leak through WebRTC in FF/Chrome
Hi everyone, I'm not sure this is the place to share this, but I though some of you might want to know: an information leak has been discovered on Firefox / Chrome, and it can be used to reveal a user's real IP address. The article is focused on VPN, but people who connect to the Tor network through a local SOCKS proxy are also affected. Demo here . -- JusticeRage ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Information leak through WebRTC in FF/Chrome
On 31 January 2015 at 05:44, JusticeRage justicer...@manalyzer.org wrote: Hi everyone, I'm not sure this is the place to share this, but I though some of you might want to know: an information leak has been discovered on Firefox / Chrome, and it can be used to reveal a user's real IP address. The article is focused on VPN, but people who connect to the Tor network through a local SOCKS proxy are also affected. Demo here. Thanks for the heads up! While I can confirm it works on FF and Chrome, my testing indicates this doesn't affect vanilla TorBrowser. (Tested on Windows) TBB disables WebRTC: https://gitweb.torproject.org/tor-browser.git/tree/.mozconfig?h=tor-browser-31.4.0esr-4.0-1#n22 for this and other reasons =) -tom ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Hibernating / Traffic limit and consequrnces for the network.
Dear list, I would like to discuss hibernating and the consequences for the network. As someone running unmetered GBit systems i like to point out that there is a downside for the network when it comes to hibernating. Usually a few days before the end of every month my systems are getting slammed with traffic / directory requests. I thought about that and came up with the theory that a lot of systems with traffic limitations are dropping out a few days before the end of the month. This means more pressure on the remaining systems in the network. If the trend that more systems with limitations are participating increases we are going to see a serious imbalance in the network at some point. I know, poor unmetered systems ;-) I would like everybody to bear this in mind when it comes to the decision Adjust the Rate or just open the gates and burn it as fast as possible. I'm in the fortunate position to be able to tribute a nice amount of money / traffic, but even systems with unmetered traffic can just help until the bandwidth / hardware limits are reached. It would be awesome if i could conbince some of you to take a step back and take a moment to look at the bigger picture. I would like to provide a good service for everyone, even at the end of the month. That's getting harder the more systems are not present at the end of the month. At this point i like to quote G. K. Chesterton: “We are all in the same boat in a stormy sea, and we owe each other a terrible loyalty.” Thank you for reading this and my best wishes for all of you. -- Sincerely yours / Sincères salutations / M.f.G. Sebastian Urbach - Religion is fundamentally opposed to everything I hold in veneration - courage, clear thinking, honesty, fairness, and, above all, love of the truth. - Henry Louis Mencken (1880 - 1956), American journalist, essayist, magazine editor, satirist and critic. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] entry guard interference?
Last bit of info. . . I realized that the two other events mentioned earlier where the hard-configured guards were unreachable were the result of local Internet connectivity outages --had slipped my mind when writing that message. So the 30 minutes (almost exactly) of guard unreachabllity was a unique event following the hard-coding of the guard nodes. As mentioned, I've seen the guards change-out entirely before adding the EntryNodes configuration despite having GuardLifetime 18 months set. Finally I checked the consensus votes for the three hours surrounding the event and both guards were in the consensus at all times and without interruption. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hibernating / Traffic limit and consequrnces for the network.
On 02/01/2015 08:02 PM, Sebastian Urbach wrote: Usually a few days before the end of every month my systems are getting slammed with traffic / directory requests. I thought about that and came up with the theory that a lot of systems with traffic limitations are dropping out a few days before the end of the month. This means more pressure on the remaining systems in the network. I was wondering why the exit probability of my relay was tripled during the past few days and now is at the usual level. Your thoughts explains it well. -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Digital Ocean: Moving to better Plan (Abhiram Chintangal)
On Feb 1, 2015, at 7:00 AM, tor-relays-requ...@lists.torproject.org wrote: On Sat, 31 Jan 2015 13:23:39 -0800, Spencer Rhodes spen...@rhodespa.com mailto:spen...@rhodespa.com wrote: If you are on the 1TB plan at DigitalOcean, you will want to set something like the following: RelayBandwidthRate 600 KB # Throttle traffic to 600KB/s RelayBandwidthBurst 1.2 MB # But allow bursts up to 1.2 MB/s rather than set a daily or monthly limit. The reason being that your server will stay up all the time instead of suddenly hibernating (essentially going offline) when it hits the cap. I'm not sure that's the best course of action. See the Tor Manual section for AccountingMax https://www.torproject.org/docs/tor-manual.html.en https://www.torproject.org/docs/tor-manual.html.en If you have bandwidth cost issues, enabling hibernation is preferable to setting a low bandwidth, since it provides users with a collection of fast servers that are up some of the time, which is more useful than a set of slow servers that are always available. Yes, I suppose that for a non-exit relay speed is more important than uninterrupted service...___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hibernating / Traffic limit and consequrnces for the network.
They already do so that you don't have all dropping at the same time. --- GPG/PGP Fingerprint E129 722B A512 105C E8BE 4705 8046 EA48 2C82 1339 https://arlen.io/key On Feb 1, 2015 3:33 PM, Zack Weinberg za...@cmu.edu wrote: On Sun, Feb 1, 2015 at 2:29 PM, Toralf Förster toralf.foers...@gmx.de wrote: On 02/01/2015 08:02 PM, Sebastian Urbach wrote: Usually a few days before the end of every month my systems are getting slammed with traffic / directory requests. I thought about that and came up with the theory that a lot of systems with traffic limitations are dropping out a few days before the end of the month. This means more pressure on the remaining systems in the network. I was wondering why the exit probability of my relay was tripled during the past few days and now is at the usual level. Your thoughts explains it well. I wonder how hard it would be to have relays randomize the start point of their hibernation period, to stabilize the amount of available bandwidth over a 1-month interval... zw ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hibernating / Traffic limit and consequrnces for the network.
Am 01.02.2015 um 20:02 schrieb Sebastian Urbach: I would like to provide a good service for everyone, even at the end of the month. That's getting harder the more systems are not present at the end of the month. I could understand the discussion if it were about providing 500 kBit continuously vs. 1 Mbit for 2 of 4 weeks. But the particular case was about providing no less than 6 Mbit continuously, which is easily enough to comfortably browse the web, for doing large downloads and probably exhausts most internet connections in unfree countries. Accordingly it's unlikely a single connection is hobbled by such a bandwidth limitation. It might be a good idea to relax this recommendation for services above some threshold, where a limitation doesn't actually cause a noticably lower quality of service. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hibernating / Traffic limit and consequrnces for the network.
On Sun, Feb 1, 2015 at 2:29 PM, Toralf Förster toralf.foers...@gmx.de wrote: On 02/01/2015 08:02 PM, Sebastian Urbach wrote: Usually a few days before the end of every month my systems are getting slammed with traffic / directory requests. I thought about that and came up with the theory that a lot of systems with traffic limitations are dropping out a few days before the end of the month. This means more pressure on the remaining systems in the network. I was wondering why the exit probability of my relay was tripled during the past few days and now is at the usual level. Your thoughts explains it well. I wonder how hard it would be to have relays randomize the start point of their hibernation period, to stabilize the amount of available bandwidth over a 1-month interval... zw ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hibernating / Traffic limit and consequrnces for the network.
On February 1, 2015 10:48:25 PM Markus Hitter m...@jump-ing.de wrote: Am 01.02.2015 um 20:02 schrieb Sebastian Urbach: I would like to provide a good service for everyone, even at the end of the month. That's getting harder the more systems are not present at the end of the month. I could understand the discussion if it were about providing 500 kBit continuously vs. 1 Mbit for 2 of 4 weeks. But the particular case was about providing no less than 6 Mbit continuously, which is easily enough to comfortably browse the web, for doing large downloads and probably exhausts most internet connections in unfree countries. Accordingly it's unlikely a single connection is hobbled by such a bandwidth limitation. Ah, thats a misunderstanding. This is not part 2 of the discussion from a few days ago. I brought it up because i see this for quite a while right now and observed it again within the last days. I thought it was time for a broader discussion. -- Sincerely yours / Sincères salutations / M.f.G. Sebastian Urbach - Religion is fundamentally opposed to everything I hold in veneration - courage, clear thinking, honesty, fairness, and, above all, love of the truth. - Henry Louis Mencken (1880 - 1956), American journalist, essayist, magazine editor, satirist and critic. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Information leak through WebRTC in FF/Chrome
On 01/31/2015 04:44 AM, JusticeRage wrote: Hi everyone, I'm not sure this is the place to share this, but I though some of you might want to know: an information leak has been discovered on Firefox / Chrome, and it can be used to reveal a user's real IP address. The article is focused on VPN, but people who connect to the Tor network through a local SOCKS proxy are also affected. Demo here As noted, it doesn't work for Tor browser. But more generally, this is why it's prudent to use gateways for Tor and VPNs. Devices using proxies should be unable to determine their ISP-assigned public IP addresses. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor and Freenode
On 01/24/2015 04:46 PM, Markus Hitter wrote: What else do I have to learn? Using Freenode and running an exit relay don't match, the technical details are secondary. First of all, thanks for running a relay! This is very important indeed. I suggest today's lesson is that the anonymity Tor provides can also be very useful for (end-to-end) authenticated connections. Remember, Tor is not always only about hiding your identity from the destination! You might like https://dud.inf.tu-dresden.de/Anon_Terminology.shtml , and compare the terms to what Tor provides. The history of Tor and Freenode is quite long and we currently can't seem to change how they treat Tor users. Better ways could be implemented, but someone would have to implemented it for their homebrew grown IRCd. In any case, if you share an IP for both ordinary traffic and exit traffic, you will unfortunately run into many more problems over time. Did you read https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines ? I strongly advise against running exits from residential connections these days, it's just too much of a hassle. Run a middle relay at home, and an exit at an exit-friendly hosting company! -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
