Re: [tor-relays] Kitten1 and kitten2 compromised (guard/hs/fallback directory)
> Could you please share some more information about the incident? From what I know and what I can speak about : A big and sensible French company was infected with Wannacry this 12/05. After infection Wannacry starts a Tor client to join it C behind a .onion address. And so connect to guard nodes (possibly bridges, directory authorities and fallback directories can be affected too, or any Tor nodes which can be joined directly by standard Tor client). Sys admin of the infected company just flag all unknown *OUTGOING* traffic as evil and report corresponding IP to cops. Which seized servers of big french providers (OVH & Online at this time) on this list the 13 and 14/05. Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Kitten1 and kitten2 compromised (guard/hs/fallback directory)
> I don't know any context or background but if you fear this could happen > to you again, I recommend to use tor's OfflineMasterKey feature (without > copying the master key to the server) with a short keylifetime (i.e. 7 > days), especially if it is a fallback dir > (which requires a tor source code change to remove it). Thanks for this feature, I don't know it ! > Could you also confirm the relay fingerprints (in addition to the > nicknames)? kitten1 86E78DD3720C78DA8673182EF96C54B162CD660C kitten2 2EBD117806EE43C3CC885A8F1E4DC60F207E7D3E Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Kitten1 and kitten2 compromised (guard/hs/fallback directory)
Dear Tor Project, Currently, my server hosting kitten1 and kitten2 (tor guard and fallback directory) is under seizure since 14/05 11h. Private key are under encrypted volume and may be protected, but please revoke immediatly kitten1 & kitten2 tor node. Those nodes are also fallback directory. Regards, -- Aeris https://imirhil.fr/ Protégez votre vie privée, chiffrez vos communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How can we trust the guards?
> The question remains whether NOT having access to my relay makes life > easier for people. Sometimes I guess you are right. But when all the big > relays get overloaded, small relays could provide MORE bandwidth than large > relays.Both your and my statements are qualitative, I would like someone > who knows the numbers to respond. Currently, big relays are not really overloaded. We have 55Gbps on guards, and overall bandwidth used at only 50%. https://metrics.torproject.org/bwhist-flags.html https://metrics.torproject.org/bandwidth.html > There are 850 MB unused memory on my $35 Pi relay that is used to 7% of its link capacity. On Pi, bottleneck is not RAM, but CPU to do crypto. Because no AES-NI extension on the CPU and very low CPU benchmark (AES256 30MBps max, compared to 500MBps with i5). And there is also an hardware bottleneck, because every components (mainly ethernet & SD card here) are connected to the same physical USB controller limited to 480Mbps for *overall* transfer (network + disk + others USB). > HUNDRED GB of RAM? I believe you mean hundred MB? In this case ditto. No no, GB. 128GB is usual on server. We even begin to see 1TB RAM machine. Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How can we trust the guards?
> 93% of the time despite having decent ultra-stable 153 KB/s bandwidth > and static IP); > The same relay is VERY reliable - totally stable for weeks, > yet still under-used only because it is small. Any people who will use your relay on a circuit will also damn you to run such small relay. This is so slow and not usable for day to day web surfing, specially if you are well connected to Internet (fiber or decent ADSL). Personnally, I have around this speed directly for my ADSL Internet connection (500/80kB), and I rant each day I have to upload something… > 4. I do not see why the current design of Tor prevents using more relays. I > do not believe the current design is limited by design in the number of > relays it can support. Memory and TCP ports ? A node need to maintain thousands of circuits. This consumes a lot of memory (400MB on one of my guard) and a lot of TCP sockets (14k sockets). Those parameters don’t scale very well if you have more nodes (65k TCP port only, or some hundred of GB of RAM). Currently, with standard hardware, seems we can’t host more than 10 or 20× more nodes than today without hitting some hardware limit. Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How can we trust the guards?
> *any* sounds a little bit too optimistic IMO, but it reduces the risk of > being deanonymized (always under the assumption of the threat model). If family name is correctly defined, Tor ensure you will only use one of those nodes on your circuits. If family name not correctly defined, Tor project will try to contact operator to define one : https://lists.torproject.org/pipermail/tor-relays/2016-December/02.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011402.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011416.html Without action, nodes may be blacklisted if suspicious. And even if not, /16 restriction will apply, and never 2 nodes on the same /16 will be used. If attacker nodes have no family name and not in few /16, we are typically in a sybil attack and Tor network tools might report the trouble. https://gitweb.torproject.org/user/phw/sybilhunter.git/ https://lists.torproject.org/pipermail/tor-consensus-health/2014-November/ 005252.html Sure, all those protections are not perfect. Adding new relays few at a time to stay under the sybil attack detection level, without common pattern (IP, / 16, node name, AS…), during a lot of time to control most of the nodes may remain undetected. But currently, seems not the case at least for guard and exit which are well known or documented most of the time or at least for the biggest part of the consensus. More than money, such undetected attack requires global organisation to subvert and subponea enough people (network admin, sys admin, companies, hardware hosting…) to build it. It's more planetary conspiracy theory than anything else. Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How can we trust the guards?
> I do not know how to interpret this table. How many guards are there at any > given time? Currently, we have 2442 guards. This number is not fix but vary each days depending of community efforts to maintain stable nodes with enough bandwidth. > Known to whom? Is there a Tor police that researches "unknown" guards? How > do you measure "known"? How do they become "known"? Something akin to key > signing parties? Secret meetings in Munich biergartens? Major operators are not anonymous and closed to the Tor project or others privacy aware association. On the top guard operator, I see Tor developers, EFF members, privacy aware email provider, privacy aware hosting provider, scientists, known hacktivists, people active on this list, VPN providers… Not at all related to three-letters agencies (or we must begin to fear about global conspiracy able to subponea all those kinds of people/association/companies on this planet during decades…). > Conversely, if someone installs a high performance relay, during the first > 70 days is there a secret police investigation giving the operator a clean > bill of health or conversely marking her as a rogue? All nodes are watched permanently by a bunch of tools : https://trac.torproject.org/projects/tor/wiki/doc/ ReportingBadRelays#Doyouactivelylookforbadrelays During the 70d, bad behaviour will be detected and associated nodes banned. And if we don’t detect anything bad during this time, so even if those nodes are controled by bad guys, we don’t care because they help the network ! Tor node selection for circuits will address this trouble and avoid you to use more than 1 of their nodes in the same circuit, preventing any anonymity problem. The best we can do in such case is to contact the operator to speak about diversity problem and to ask for shuting down some nodes if we consider he controls more consensus he should. Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How can we trust the guards?
> > Tor model breaks down when facing a modest government adversary for the > > simple reason that having only 7000 relays total, with a minority of > > them carrying most of the traffic, invites cheap infiltration and > > takeover by state adversaries. > > Yeah, that's a problem :( That’s a theorical problem. Currently, most of the major guard operators are well known people and no doubt they’re not engaged with three-letter agencies. https://github.com/ornetstats/stats/blob/master/o/main_guard_operators.txt Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How can we trust the guards?
> @Aeris > > I do not see how Sybil attacks relate to my question. The adversary will > simply set up new nodes, without messing with attacking identities of > existing ones. Sybil attack is not attacking identity, but just running bunch of relays. > As to the rest of it, let us calculate. Assuming that the adversary wants to > control 4000 nodes for 3 years, the 70d startup period is irrelevant and > negligible. But because they have guard flags, those 4000 nodes must be on the top 25% bandwidth nodes. So this assume we have around 16k nodes currently. Which is false. And current average guard bandwidth is around 40Mbps, so your attacker have 156Gbps capacity… And because of Tor nodes selection, those 4000 nodes must be on the more /16 network as possible. > Assuming further that operating the relays will cost the > adversary $20/month each, the total "investment" required would be > 20x12x3x4000=less than $3million > > That’s $1million a year to control most of the Tor nodes., You call this > "costly"? This amount is a joke, a trifle, petty cash for any US or Russian > government agency. FIFTY times this amount is STILL petty cash, so in case > you think $20/month is not enough to run a relay, make it $1000 a month. Having is not enough. You can’t just send in hardware and expect to be guard. You need to prove your worth to the network to have guard flag. And you also need intelligence, because your node must be VERY differents each others or only few of your guard will be used (same /16 network, same country, same operator => never 2 nodes on a circuit or guard set). > So I repeat - how is this prevented? Re-read my first post. Tor node selection for circuit, Tor node guard flag assignment. And because currently most of guards are controlled by well known or smart enough people, we don’t have such attacker. Controlling all guards is NOT a serious problem ’til you also control other nodes (middle or exit). If you think such attacker exists, just don’t use Tor, this is EXACTLY the threat model Tor can’t avoid and expressed on the paper. Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How can we trust the guards?
> Whats the trust mechanism (if any) to ensure that the majority of guards > are not hijacked by adversaries? See https://blog.torproject.org/blog/lifecycle-of-a-new-relay * You need to wait around 70d to be a fully ready guard relay consuming all the possible bandwidth. * Any sybil attack will be discovered even before having the guard flag at all (8th day). * And you have to provide a lot of bandwidth to the network to be on the top quarter of relay to have the guard flag. So it will be difficult for an attacker to hijack enough guard nodes to be really dangerous. Too costly (bandwidth), too long (70d) and too visible. Remember too that your client use only few guards at each time and rotate them only each 4 to 8 weeks. So even if evil guard appear, you have to wait at least 4 weeks to be in danger if in danger at all (probability is low to peak an evil guard at the next rotation). And last, even if you use an evil guard node, attacker need to control an other node (middle or exit) on one of your circuit to break anonymity. So, evil guard nodes are not a big problem :) Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Rampup speed of Exit relay
> Scaling up on more hardware is always an option, but I really want to > push the limit of the exit node, as the others won't be exits (Local > network design, really) , and exit traffic is always more > interesting. When I say another instance, it’s on the same hardware. Because Tor is not fully multi-thread/multi-core, you have to run another Tor daemon on the same host to use 1 more CPU core and so drain another 150-300Mbps. Currenly, you can start up to 2 Tor daemons per IP, there is a limitation to avoid Sybil attack. Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Rampup speed of Exit relay
> 17 MBytes/s in each direction. From Atlas graph, your node is currently growing up, so wait few weeks more to have the real bandwidth consumption, but don’t expect huge change. 17M*B*ps is 140M*b*ps and you already have a good relay :) This is around the speed expected for standard CPU (150 to 300Mbps per Tor instance, best CPU available can "only" drain around 500Mbps). And your CPU have all chance to be the bottleneck at this speed. Tor is not multi-core at the moment and so you can’t be able to fully use your CPU capacity. For example, if you have a 4-core CPU, don’t expect to have more than 0.25-0.3 load with only Tor (1 core fully used). You have to start another Tor instance to use a little more your CPU (1 other core) and so to drain additionnal 150-300Mbps. Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why can't I see more traffic? (is my banana too weak?)
> According to 'openssl speed aes-128-cbc' the Allwinner A20 CPU in Banana Pro > is capable of about 25 MBytes/sec in AES performance. While that won't > translate 1:1 into Tor performance, as Farid noted in his case the CPU > isn't being a bottleneck, with only 10-20% CPU load observed. I don’t understand very well this fact, but CPU can be the bottleneck even if load or CPU usage not at full capacity. One of my Tor guard relay have the same CPU behaviour (see screenshot enclosed). 2 instances at 50-60% CPU usage (as reported by htop), load around 0.70-0.80 (4 cores), RAM at 20% (400MB/2GB) but bandwidth not saturated (20Mbps only on a 200Mbps line). Perhaps because of the multiple changes of context (AES crypto, Tor software logic, network IO…) and so a lot of wait/IRQ (as visible on the screen) and not a fully used CPU. > Also seems unclear why it didn't get the guard flag for so long, does your > public IP address change from time to time? Or do you turn the relay off and > on for whatever reason. Perhaps a low bandwidth ? Babylonian seems to be on the lower part of guard relay (2146/2313), possible it hadn’t enough bandwith before end of august to get guard flags ? Only the 25% fastest relays can get the guard flag. Today it’s around 2.5 MBps advertised / 1MBps measured. Babylonian is just at the limit (2.45MBps advertised, 600kBps measured). <3, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why can't I see more traffic? (is my banana too weak?)
> Could it be that it is due to the quite slow hardware, even though I know > that it is able to push more traffic? I notice too your relay got the guard flag very recently. So your relay is currently probably not at full capacity and rather at a low one (relay usage drops at guard flag assignment). You have to wait 60 days from your guard flag to reach this point. See https://blog.torproject.org/blog/lifecycle-of-a-new-relay, you’re currently at the beginning of the 3rd phase. <3, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why can't I see more traffic? (is my banana too weak?)
> Could it be that it is due to the quite slow hardware, even though I know > that it is able to push more traffic? Yep, surely. You currently push 3Mbps of traffic, which is correct for this kind of hardware. All "cheap" hardware (raspi, banana, olimex, pine…) suffer of the fact they don’t have crypto hardware acceleration and do software encryption. And so is very slow (10-100× factor) even compared to low end amd64 CPU with AES-NI extension. Generally speaking, the bottleneck of a Tor relay is CPU, not bandwidth. Even high end Intel CPU is not able to deliver more than 300Mbps (one core of 2Ghz Xeon is ~ 100Mbits, standard CPU is ~ 300Mbps, best known Tor relay currently handle 500Mbps). <3, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new relay package for Ubuntu 16.04+
> Ubuntu/Debian doesn't have the latest version of Tor. You should use the > official repository: https://www.torproject.org/docs/debian.html.en I already use this repo for all my relays :) <3, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new relay package for Ubuntu 16.04+
> Currently not on Xenial and Jessie (even in backport). >< Don’t match 2.8.6 too : snap ba16ce2958119a238d7931e709f30e932938218f ubuntu yakkety tor_0.2.8.6-3ubuntu1_amd64.deb 5839f7b8bdc74cc26c829452d458d5c797ff3666 official tor tor_0.2.8.6-3_amd64.deb 6f2f4118b69420882022b526b956d65dc22a0b12 official tor xenial tor_0.2.8.6-3~xenial+1_amd64.deb 98677a0bfd0d3c22f342b44b824ba4d03f8facd3 IMO, if you rebuild from scratch, you have to achieve reproductible build, to allow post-build verification (and so, trustability of your snap). <3, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new relay package for Ubuntu 16.04+
> Aeris, I should be worried if any of those matched. Did you know 0.2.8 is > out? Currently not on Xenial and Jessie (even in backport). >< <3, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new relay package for Ubuntu 16.04+
> much less an untrusted tor package For information, the tor binary inside the snap doesn’t match any official upstream I can find… SHA1 Snap ba16ce2958119a238d7931e709f30e932938218f Xenial (tor_0.2.7.6-1ubuntu1_amd64.deb) 997b717acaf2077708beba39a05adb30c014dfb2 Debian Jessie backports (tor_0.2.7.6-1~bpo8+1_amd64.deb) cd63c5e01481a2b195bcb23c3d96dd81fb4f722d Tor project repo (tor_0.2.7.6-dev-20160824T140713Z-1_amd64.deb) f64cf21322c26372457cffcb7aeb97dd7768b697 Tor project repo (tor_0.2.7.6-dev-20160824T140713Z-1~d70.wheezy+1_amd64.deb) 6ba3b089029c1ae77ffcfb8fe2ee39335066b98a Tor project repo (tor_0.2.7.6-dev-20160824T140713Z-1~xenial+1_amd64.deb) 8a2387c986ae98df7b2b78463aa6104ae5ebd080 <3, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new relay package for Ubuntu 16.04+
> This is a matter of perspective on the "security" definition. Yep of course :P For desktop-purpose, snap can eventually be interresting. You only put yourself at risk. For server-purpose, you also put your users at risk, and in case of Tor, it’s very safer for them to run Tor with at least OpenSSL & Tor up-to-date, and so to use and follow official upstream release. <3, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new relay package for Ubuntu 16.04+
> 2) security is better Sorry to say that, but : no. It’s very weaker than plain old Debian package. Currently, your snap embeds : libevent openssl pthreads libasan2 libubsan python 2.7 python-torctl tor-arm tor Any security change on one of those embeded libraries require *you* rebuild and upload a new snap to fix the problem. This is very problematic for at least openssl (very frequent security fix) and tor/torctl/tor-arm (now, *you* need to follow every official releases of those 3 parts and deliver a new snap each time). On a plain old Debian package, a security change impacts only *one* package (not *all* apps) and require only *the maintainer* of the lib package (not *all* apps ones) to rebuild and deploy. And this fixes *every* other package using this lib without extra step. Snap, docker and more generally all packaging system embeding libs inside are just a nightmare in terms of security update. <3 -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
> kitten3 doesn't have a DirPort configured. Relays need a DirPort to be a > fallback directory mirror. Let me know if you are able to configure a > DirPort for it. > > Also let me know if you want to opt-in or opt-out other relays in that > family. Thanks for the report, corrected ! For others nodes of my family, avoid kitten5 and 6 at this moment, potential migration with IP change in few months. Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
> Are you *absoultely* certain that the config > was not fiddled with at the time of this event? After grepping some logs, seems 13/12 was the day of a Tor upgrade : 2015-12-13 10:47:31 upgrade tor:amd64 0.2.7.5-1~d80.jessie+1 0.2.7.6-1~d80.jessie+1 2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1 Timing is good compare to the 10:48:46 of the consensus ! But I don’t remember a config change after that, perhaps only on /usr/share/ tor/tor-service-defaults-torrc or on a default config param change ? And perhaps the Tor reboot cause the DirPort to be temporarily disabled (seems not human, only 2s duration) ? Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
> Here's the latest list of fallback directory candidates: > https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_di > rs.inc.20160112 Is this list removes already included fallback nodes ? Previously, my node kitten1 was on the list, but not on this one. (I already opt-in for it inclusion on december, with my others nodes (kitten[1-4])). -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
> DEBUG:root:86E78DD3720C78DA8673182EF96C54B162CD660C not a candidate: changed
> address/port recently (2015-12-13 11:00:00)
Hum… Don’t know how is it possible, this relay has the same IP/port since it
creation 1 year ago.
From CollecTor, seems there is only a single network glitch, and only on the
DirPort (OR port stable).
$ wget https://collector.torproject.org/archive/relay-descriptors/microdescs/
microdescs-2015-12.tar.xz
$ tar xf microdescs-2015-12.tar.xz
$ cd microdescs-2015-12/consensus-microdesc
$ rgrep kitten1 | awk '{print $2,$3,$6,$7,$8}' | sort | uniq -c
1 kitten1 hueN03IMeNqGcxgu+WxUsWLNZgw 62.210.124.124 9001 0
735 kitten1 hueN03IMeNqGcxgu+WxUsWLNZgw 62.210.124.124 9001 9030
$ rgrep kitten1 | grep "9001 0"
13/2015-12-13-11-00-00-consensus-microdesc:r kitten1 hueN03IMeNqGcxgu
+WxUsWLNZgw 2015-12-13 10:48:46 62.210.124.124 9001 0
:'(
--
Aeris
Individual crypto-terrorist group self-radicalized on the digital Internet
https://imirhil.fr/
Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/
signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] atlas not showing 3 days and 1 week graphs
> This is the result of a change made in Tor 0.2.5 that causes the relay > to only record bandwidth data for 24 hour period (instead of 4 hours). Some others relays have no 1 year consensus graph or later, but bandwidths graph are ok. See https://atlas.torproject.org/#details/ 2EBD117806EE43C3CC885A8F1E4DC60F207E7D3E Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor hidden services & SSL EV certificate
> A few hidden services have added an > HTTPS cert but I think that's mostly for a publicity stunt than anything > else. As indicated in the roger’s lecture, HTTPS is usefull for HS : - browsers handle more securely cookies or other stuff in HTTPS mode, avoiding some possible leaks - because anybody can create an HS and proxify any content, X.509 certs allow users to verify the authenticity of the HS (you are on the official Facebook HS if you have a cert with facebook.com *AND* facebookcorewwwi.onion inside) -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors
> we will only add your relay if you opt in. You obviously have my opt-in for my kitten1 (86E78DD3720C78DA8673182EF96C54B162CD660C) relay ! <3, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Faravahar messing with my IP address
> I just got something strange too: > > Oct 22 20:42:24.000 [notice] Guessed our IP address as 77.206.60.235 > (source: 154.35.175.225). > Oct 22 20:42:25.000 [notice] Our IP Address has changed from > 77.206.60.235 to 149.18.2.82; rebuilding descriptor (source: > 199.254.238.52). Hello guys, Same trouble on my node : Oct 24 11:21:20.000 [notice] Our IP Address has changed from 62.210.124.124 to 18.82.0.94; rebuilding descriptor (source: 154.35.175.225). Oct 24 11:29:58.000 [notice] Our IP Address has changed from 18.82.0.94 to 62.210.124.124; rebuilding descriptor (source: 131.188.40.189). Contact with another French Tor node operator, impacted too the same day : Oct 24 20:57:10.000 [notice] Our IP Address has changed from 81.57.127.22 to 212.27.38.252; rebuilding descriptor (source: METHOD=RESOLVED HOSTNAME=ecuri.es). Oct 24 21:00:13.000 [notice] Our IP Address has changed from 212.27.38.252 to 81.57.127.22; rebuilding descriptor (source: METHOD=RESOLVED HOSTNAME=ecuri.es). Possible there is some kind of attack on the network ? Seems most of trouble reported on this thread imply French IP or French Tor node. My country recently pass a law about state mass surveillance, with deployment of « black box » for security interception. Could it be related ? Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] very erratic tor usage
I run a relay for about 6 weeks now, on and off a bit because of power outages. I see extremely erratic traffic usage. From 5kb/sec to 250 kb/sec. Hello, If your relay is flapping, you can’t have a high consensus, and so only little number of Tor clients will use it. You need to have stable and long running relay to gain more consensus and bandwidth usage. And it take more than 68 days for a stable relay to reach full capacity. See https://blog.torproject.org/blog/lifecycle-of-a-new-relay Regards, -- Aeris Individual crypto-terrorist group self-radicalized on the digital Internet Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Encryption in French servers
I know in France it's illegal to encrypt data so if I run a tor relay in a French server I would have any problem? Crypto is not illegal since 1999 in France. Do you have any source about what you advance ? There is the new surveillance bill/law, but not currently applicable (need formal application details before that) and even this law doesn’t forbid crypto. Regards, -- Aeris, french citizen Groupe crypto-terroriste individuel autoradicalisé sur Internet Protégez votre vie privée, chiffrez vos communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Questions about GUI monitor
I'm unaware if Vidalia is still operational in its current state. Using Vidalia from Debian repo and still operate correctly. -- Aeris Protégez votre vie privée, chiffrez vos communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor weather - signature not found
Hi all, I have recently converted a bridge to a relay. Its fingerprint is 0D14A4498E7D1854696CC07548653EA4CD3CB2DA. I wanted to subscribe to Tor Weather but when I try I get the We could not locate a Tor node with that fingerprint. error. As far as I know, bridge fingerprints are obfuscated before publishing. Perhaps this is the reason of the error ? -- Aeris Protégez votre vie privée, chiffrez vos communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
