- tor-relays - lists.torproject.org

Tor Relay Operators Meetup at 31c3 *moved* - 28.12. 13:00
by Moritz Bartl 23 Dec '14

23 Dec '14

Hi, I had to move the meetup slightly in time and to a different room. I was told by CCC orga that they need the original room for Engel meetings. NEW DATE: 28.12.2014 13:00 LOCATION: HALL C https://events.ccc.de/congress/2014/wiki/Session:Tor_Relay_Operators_Meetup See you! -- Moritz Bartl https://www.torservers.net/

1 0

Tor Relay Operators Meetup at 31c3 - 28.12. 14:15
by Moritz Bartl 23 Dec '14

23 Dec '14

Hi, Torservers.net invites Tor exit relay operators and organizations to a meetup. If possible/relevant, for example if you're a member of one of the 'Torservers partner organizations', please prepare some slides on your activities. You're obviously also welcome to suggest sessions as a member of the broader relay community! We will do quick presentations on recent and future activities around Torservers.net, talk about events relevant to the Tor relay community, and what lies ahead. https://events.ccc.de/congress/2014/wiki/Session:Tor_Relay_Operators_Meetup 2014/12/28 14:15 - 16:15 See you there! -- Moritz Bartl https://www.torservers.net/

5 8

DDoS attack targeted on my exit node
by Michael Renner 22 Dec '14

22 Dec '14

Hi, my tor exit node was targeted with two DDoS attacks, one on 2014-12-20 01:00 CET and one on 2014-12-22 18:00 CET [1], both lasting about 5 minutes each. This alone wouldn’t be too noteworthy if it weren’t for the fact that a) there’s a certain state of alarm WRT the Tor networks integrity and b) these are the only attacks my ISP has on record for the over 2.5 years of operating the Tor Exit node. If no other operators have noticed anything out of the ordinary (given by the silence on the list) this is most likely a fluke (getting rid of pesky IRC users?), but better be safe than sorry. best, Michael [1] http://i.imgur.com/Zu9UkW3.png <http://i.imgur.com/Zu9UkW3.png> Summary screen

3 2

ntp needs attention
by Felix 22 Dec '14

22 Dec '14

Hi See: https bugs.debian.org/cgi-bin/bugreport.cgi?bug=773576 Debian will be fixed by 'apt-get update' and 'apt-get upgrade'. dpkg.log tells if the fix is in place: https security-tracker.debian.org/tracker/CVE-2014-9293 ... Cheers!

3 2

Hibernation and Guard flag
by Filippo Valsorda 21 Dec '14

21 Dec '14

Hello, I set up a relay node on my VPS to eat up all that unused bandwidth, and it's doing well so far [1]. Since I have ~3TB per month and I heard hibernation is preferable to throttling, I set up monthly accounting with that cap. However I have two doubts: 1. Is daily accounting preferable? That is, what's best, shorter or longer hibernation periods? 2. How does hibernation play with the Guard flag? I know Guards rotation plays a crucial role in users privacy, and it seems to me hibernation would really hurt a client that selected you as its Guard, since it will have either to run with one less available Guard, or pick a new one and increase its risk. Also, I know there are talks about making only 1 Guard selected, how would that play with hibernation? N.B. please cc me into the replies, I might not be getting only-in-list replies. Thanks, Filippo [1] https://globe.torproject.org/#/relay/2EC042F4274CC8A54381C78E8D1BF322FA26A0…

2 1

Re: [tor-relays] Platform diversity in Tor network [was: OpenBSD doc/TUNING]
by teor 16 Dec '14

16 Dec '14

> From: Richard Johnson <rdump(a)river.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Platform diversity in Tor network [was: > OpenBSD doc/TUNING] > > On 2014-11-05 10:47, Libertas wrote: >> I appreciate your interest! Also, I hope I'm not speaking with too >> much authority. If anyone here has more OpenBSD experience than me, >> please send addendums or corrections. > > Maybe call this an addendum? Some version of the following work in progress > is going onto our local documentation store for others maintaining our > OpenBSD relays. > > It's a bit long-winded for inclusion in doc/TUNING per > https://trac.torproject.org/projects/tor/ticket/13702 , as it's intended to > educate *BSD and Linux sysadmins about a smidgen of the why behind the > tuning recommendations, as well as point at further exploration. > > > Richard > > ------- > Our OpenBSD tuning for Tor involves: ... > 4) Probably running more than one relay on a host to use available CPU > cores and bandwidth. ... > 4) Loading more CPU cores > > If you have one of your CPUs maxed out running a Tor relay, with the other > CPU(s) mostly idle (see top(1)), yet you have bandwidth to spare still, you > can run additional Tor instances to sop some of it up. > > The sanest way to handle this is to make each relay a stand-alone entity > with a naming scheme to keep them straight. Here, we'll use "tor#" for every > relay past the first. > > Make per-relay directories in /var owned by _tor:_tor mode 700 > drwx------ 5 _tor _tor 512 Jan 13 18:52 /var/tor/ > drwx------ 5 _tor _tor 512 Jan 13 22:39 /var/tor2/ > drwx------ 5 _tor _tor 512 Jan 13 22:39 /var/tor3/ > ... > Copy the tor startup script /etc/rc.d/tor to match the naming scheme. > /etc/rc.d/tor2 > /etc/rc.d/tor3 > ... > Copy the torrc from /etc/tor/torrc. > /etc/tor/torrc2 > /etc/tor/torrc3 > ... > Modify /etc/tor/torrc2, /etc/tor/torrc3, ... so they refer to their > appropriate private DataDirectory and PidFile, listen on the appropriate > ports and IP addresses, and have the appropriate exit policies. (Remember > that the public Tor network will by design ignore more than two relays per > IP address.) > DataDirectory /var/tor2 > PidFile /var/tor2/pid > ControlPort 9222 > Address 10.2.2.2 > ORPort 8222 > DirPort 7222 > ... > DataDirectory /var/tor3 > PidFile /var/tor3/pid > ControlPort 9333 > Address 10.3.3.3 > ORPort 8333 > DirPort 7222 > ... > Set each relay to launch at system startup via the named /etc/rc.d scripts in > /etc/rc.conf.local's pkg_scripts. > tor_flags="${tor_flags} -f /etc/tor/torrc" > tor2_flags="${tor2_flags} -f /etc/tor/torrc2" > tor3_flags="${tor3_flags} -f /etc/tor/torrc3" > ... > pkg_scripts=" ... tor tor2 tor3 ..." > Set openfiles-max for each named pkg_script from /etc/rc.conf.log in > /etc/login.conf. > tor:\ > :openfiles-max=8192:\ > :tc=daemon: > tor2:\ > :openfiles-max=8192:\ > :tc=daemon: > tor3:\ > :openfiles-max=8192:\ > :tc=daemon: > ... > Remember to allow inbound traffic to the additional ports set in > /etc/tor/torrc[#] in your /etc/pf.conf. Why give advice on "tor3" when the current consensus parameter for limit per IP is 2? In case someone has an extra IP? Or are you hoping we will increase the consensus parameter to 3? I could revive that suggestion, by the way - it stalled as trac #13414 due to concerns with making sybils easier. https://trac.torproject.org/projects/tor/ticket/13414 Maybe we could try for 3 per IP? teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

2 1

Platform diversity in Tor network [was: OpenBSD doc/TUNING]
by grarpamp 16 Dec '14

16 Dec '14

On Tue, Nov 4, 2014 at 12:25 PM, Libertas <libertas(a)mykolab.com> wrote: > I think it would be a good idea to add OpenBSD to doc/TUNING because [...] > promoting OpenBSD relays benefits the Tor network's security. Absolutely. Not just due to OpenBSD's security positioning, but moreso from network diversity. Windows is its own world. But if you're a Unix admin there's no reason Linux should be deployed 20x more often than [Free/Open]BSD. It's ridiculously counter to meeting diversity goals, especially with bandwith weighting if one platform is getting grossly disproportionate traffic than another. Just pick one of the two BSD's and run it instead. FreeBSD in particular is well suited to the OS and network needs of Tor. And knowing how to admin more Unixes will serve any admin well. 5950 Linux 1593 Windows 173 FreeBSD 55 Darwin 44 OpenBSD 7 NetBSD 6 SunOS 4 Bitrig 2 GNU/kFreeBSD 1 DragonFly

12 29

Out of memory message
by Logforme 15 Dec '14

15 Dec '14

I run the relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC3). Yesterday I saw new messages in the log file: Dec 06 09:28:13.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 06 09:28:16.000 [notice] Removed 1040388096 bytes by killing 1 circuits; 14631 circuits remain alive. Do I read that correctly as one circuit using 1GB of memory? Here's the first lines from the top command: top - 09:40:41 up 31 days, 1:51, 1 user, load average: 0.53, 0.62, 0.66 Tasks: 95 total, 3 running, 92 sleeping, 0 stopped, 0 zombie %Cpu(s): 10.2 us, 2.0 sy, 0.0 ni, 83.2 id, 0.0 wa, 0.0 hi, 4.5 si, 0.0 st KiB Mem: 3950828 total, 3833092 used, 117736 free, 49696 buffers KiB Swap: 3212284 total, 1296392 used, 1915892 free, 99168 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2680 debian-t 20 0 4134m 2.8g 24m R 63.5 73.4 27199:00 tor The relay is running on a dedicated debian box with 4GB of ram. It usually only uses about 0.5GB but now it is maxed out. The relay and the box is so far working fine, I just wonder if this is some kind of attack or if anything is wrong and if there is anything I should do about it.

5 8

Changing ulimit for debian-tor
by Lluís 12 Dec '14

12 Dec '14

The limit to open files is set to 1024 by default in my system. So it is for the "debian-tor" user, too. It seems to me a bit low. I tried to rise it a whit through "sudo" and getting a shell for debian-tor, but it doesn't work. Can I use PAM-LIMIT with tor ? If not, how can I set ulimit for debian-tor when booting ? And when restarting tor ? BTW, may the open files ulimit preclude a relay to get the "guard" flag ? thanks in advance, Lluís Spain

5 6

specifying your own entrance and exit nodes
by Seth 11 Dec '14

11 Dec '14

Assuming there are certain Tor notes being run by parties hostile to my own interests, what are the pros and cons of specifying one's own list of trusted entrance and exit nodes? I run a Tor relay at home 24/7 and use that as my entrance point. I do this to provide cover traffic for my own Tor use as well as help out the network. I also try to use Tor for all my daily web browsing when possible. This has given be a lot of headaches. Besides the demoralizing barrage of Cloudfare captchas, I've had a lot of problems with dropped connections, timeouts, SSL cert warnings, fatal errors connecting to HTTPS sites. I started to get a gut feeling, warranted or not, that some exits nodes might be meddling with my traffic. To combat this I changed the configuration on my local Tor relay to use only exit nodes run by organizations or people that I felt I could trust. I didn't bother with specifying entrance nodes because I could not see what the gain would be. This seems to have curbed some of the problems, with the tradeoff that responsiveness is much more inconsistent. I'm just curious if restricting exit nodes to a few dozen that you trust effectively defeats most of the purpose of using Tor. What would be the bare minimum of Tor exit nodes a person would need to use in order to make life difficult for the Panopticon surveillor scum? If this post is more appropriate for Tor-talk, please let me know

3 3

Re: [tor-relays] No obfs3 traffic at all on bridge
by TheGreatWent 09 Dec '14

09 Dec '14

From: Marco Gruß<tor-relays(a)email.todmue.de> > Hello, > > my obfs3 bridge has now been up for > 20 days. > > I have iptables rules in place to count packets. To date, > I have not seen a single packet to either the obfs3 or > the scramblesuit port. Both are working though, I just > tried them with the Tor Browser. > > Is this a good sign (i.e. the bridge is still in reserve) > or a bad sign (something's wrong)? > I set one up around the same time and haven't seen any traffic either. Maybe there is a surplus of them? I couldn't figure out what the different bridge pools were or how they got allocated to them.

1 0

exit policy to reflect country-wide ban
by Vladimir Ivanov 08 Dec '14

08 Dec '14

hi. Recently, github was blocked in Russia (see discussion here: https://news.ycombinator.com/item?id=8692584) The ban is executed by all major ISPs (comply with this regulation is necessary to keep the telecom license so no ISP is risking to disobey), this means that if your exit node happens to be in Russia, you're out of luck when you try to connect to github. Some suggest marking exit nodes in Russia as bad exits because connecting via them leads to various problems (like node provider doing MitM on all github https connections). Here is an example: https://twitter.com/wiretapped/status/539934125293961216 I think, if Russian exits operators implement reduced policy rejecting github, that would be better solution: they're still usefull for all other sites and a client would access github using a tor exit elsewhere. Do I miss something here? Are any disatvantages of this? More general, if a network, a particular exit node is connected to, blocks some IP addresses, is it wise to reflect those changes in the node's ExitPolicy? BR, Vladimir

4 5

No obfs3 traffic at all on bridge
by Marco Gruß 07 Dec '14

07 Dec '14

Hello, my obfs3 bridge has now been up for > 20 days. I have iptables rules in place to count packets. To date, I have not seen a single packet to either the obfs3 or the scramblesuit port. Both are working though, I just tried them with the Tor Browser. Is this a good sign (i.e. the bridge is still in reserve) or a bad sign (something's wrong)? Thanks for any help! Marco

1 0

According to globe and atlas, bridges have guard flags, while they actually don't have them at all...
by Justaguy 07 Dec '14

07 Dec '14

What is the cause for this behavior? https://globe.thecthulhu.com/#/bridge/286FD249840142D1C7536C2D12FDBE5EA63AD… https://atlas.thecthulhu.com/#details/286FD249840142D1C7536C2D12FDBE5EA63AD… -- Contact: Irc, justaguy @ Freenode or OFTC OTR fingerprint: FF6D1AC2 13F38B15 EDB21522 D3530A6F 6EE01996

2 1

Re: [tor-relays] Guard flag and some irregularities
by Sebastian Urbach 06 Dec '14

06 Dec '14

On December 6, 2014 9:41:34 PM Rafael Rodriguez <rafaelr(a)icctek.com> wrote: Hi, > https://atlas.thecthulhu.com/#details/48ADFCC561402D7EBB1CDE233F206B01D8FA0… > > > 1- Is it ok for the Guard flag to come and go so often? I do not see > anything wrong with my relay and it is pushing up to 12MBs at times. >From what i can see the numbers are way lower than that. Recently the criterias to qualify as a guard changed, i assume that you drop out of the guard position because you don't make the cut all the time. If im not mistaken the number of guards dropped roughly 50 % after the changes were implemented. > Most of the time, my relay pushes between 3-7MB/s constantly and that's > fine. But there are occasions in which I see it spike and send out as > much as 12MB/s I'm struggling with the numbers, if you take a look at the graphs you are not getting this much traffic. Maybe your system is under attack (DoS, DDoS) ? It does not look like it's regular Tor traffic ... -- Sincerely yours / Sincères salutations Sebastian Urbach ----------------------------------------- Definition of Tor: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

2 1

Guard flag and some irregularities
by Rafael Rodriguez 06 Dec '14

06 Dec '14

https://atlas.thecthulhu.com/#details/48ADFCC561402D7EBB1CDE233F206B01D8FA0… 1- Is it ok for the Guard flag to come and go so often? I do not see anything wrong with my relay and it is pushing up to 12MBs at times. Most of the time, my relay pushes between 3-7MB/s constantly and that's fine. But there are occasions in which I see it spike and send out as much as 12MB/s when I have set a limit of @6MB/s. 2- Is Tor not respecting the limits? If it doesn't respect the limits consistently it might as well overkill my budget which translates into me killing the relay.

2 2

Running a New Relay
by Abhiram Chintangal 06 Dec '14

06 Dec '14

Hello, About two days ago, I started running my first tor relay using a digital ocean vps instance. Yesterday, I found this nice article[1] about the life-cycle of a tor relay. It was a great read and I think I understanding of how tor works has improved quite a bit. Currently, my relay[2] whose up-time is roughly 2 days 18 hours doesn't have any active circuits ( via tor-arm). Since its in the unmeasured phase( days 0-3) shouldn't it be making circuits back to itself? I believe the number that was mentioned in the article was four. I apologize if my question seems silly. Thanks! -- Abhiram Chintangal I guess we agree with reason, but now it's a matter of disposition [1]https://blog.torproject.org/blog/lifecycle-of-a-new-relay [2]: https://atlas.thecthulhu.com/#details/0D63999A202B34EF1CD9669BC45B0A697D9BF…

2 1

Atlas slow/not working?
by Abhiram Chintangal 06 Dec '14

06 Dec '14

Hello, I am not able to check my relays status via Atlas for the last two days. Any ideas? Thanks -- Abhiram Chintangal I guess we agree with reason, but now it's a matter of disposition.

5 5

ArchWiki article about fast relay configuration
by usprey 06 Dec '14

06 Dec '14

Hi List I have written my own notes into https://wiki.archlinux.org/index.php/Tor#.2B100Mbps_Exit_Relay_configuratio… . All and any feedback will be appreciated! Are there any privacy concerns about using pdnsd to cache DNS locally?

1 0

Planning a relay
by TT 06 Dec '14

06 Dec '14

I'm thinking of running a relay, and i've a few questions regarding the requirements and the general setup. So far this is just planning. The hardware would be clean and in my possession, but the connection would go through a Swedish-based VPN provider because i'm not interested in running it through my own IP address. The provider endorses Tor and places no limits whatsoever on the services run through their connection, has port forwarding and allows exits, so no issues there. They also have a strict no-logging policy, but words are cheap so you never know. I guess the first question should be whether such a relay would be welcome on the Tor network in the first place? I am aware that connecting to Tor through a VPN isn't generally recommended, but what about running a relay through one? Better idea, or a ridiculously bad one? Second, while it would run on a (nearly) dedicated 100mbit connection, i do not have dedicated equipment. The machine needs to be taken offline between every 2-4 weeks, for some days at a time. Frequent OS updates also often require reboots in addition to this downtime. So much for a stable flag, but more importantly i need to know if this behavior is undesirable for running middle/exit relays? If so, would a bridge be better suitable with the tools i have at hand? Third, regarding running bridges. The Tor Project FAQ states running your own bridge might improve your own anonymity. I assume this means you would manually set up your TBB to connect to *your own* bridge, is this correct? And finally, since the bridge would run on a separate (VPN) IP address, would this make a difference (re:anonymity) for better or worse if you connected through it yourself? I'm likely missing something here because it seems it would basically be the same as simply connecting to Tor through the VPN client alone. Thanks.

7 9

Tor Server - DDOS or High Load
by webmaster 05 Dec '14

05 Dec '14

Hello Folks, I'm running a relay tor server since several years. Last week (24 Nov) I noticed a high load on the tor server (cpu load 100%). After some investigation i found out that tor causes the high load. After killing the process the load decreases to a normal level, but after restarting the tor process again the load increases again. Arm log: Could not open "" for writing: To many open files. or Failing because because we have 1017 connections already. Please raise your ulimit -n Tor's file descriptor usage is at 91%. If you run out Tor will be unable to continue functioning. At first I thought: Fuck, someone intruded into my machine. But after some looking through Arm I found many (>100) INBOUND connections. After one hour and some iptables tuning the cpu load decreases. Could the high load caused by an attack on my machine or is this just some small load peak? Hope for some reply -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (MingW32) mQENBFHMmT8BCAC0smvU7Bq1ABxAhvBRn7d4ekkk95aCE4TTQo4wy1z/rGLhQfdt dhiD+Vy61vGrsdK3ei5sW6rBvX2m8+YmBi+8AAgSiZmS0JM3Zz3cmTi5oh0D/yM8 4aDj7wQYfJyzSmYN8InAQ5eA77lwIdqG27kR9wga2szeJwCnWReta0R+7YFkpUW+ zUlf4SWcUx5SmBsaiELQpm+Qcn+fyopo12RX6YVmoNPBvN2nDXDnRhUCKGc+0xhD UrBpCHrApK6sTnMsD34ClCLTL2L1gckQ0AsQqY3PJlx3R8kIJxlmr6R3WnjPMIG0 lqrukB9PcOrHM1MZXK1gK6AtypHBN98lr8Z9ABEBAAG0KndlYm1hc3RlciA8d2Vi bWFzdGVyQGRlZmNvbi1jYy5keW5kbnMub3JnPokBPgQTAQIAKAUCUcyZPwIbIwUJ CWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQcN1vxvRQl+0SEwf+KXjf YtiSUSVS11uqeQ/8g46NwmNa91P3toZvEd7vhLSbjnL9bi/vApzNnUTGT3VP4/NA dg9SbR4qKlSr8T+YikRMV3tiuiVq8m7g00qM9y8MIomwJTounz8VdO/aJXFSOxAK Bb6ElREADspCzr2qSZCnozWUzbd+b8owbGeRRq3e33Aa5Nlm/xDRxGDWANbaIA8q Gkibvy3vWEwrxiwsakvHGaEZnPEtlNm3M1xcmFAuyl73qzUMkLN0u9E/2igo4EB5 EdMb5Ab5hfWdljxBqJr0tsvMfSK4VkzMCbKYkTqHZIRPQnhiSBE6Yo1Q6RCl/Hht bkvU4RA0J+NkXMZljrkBDQRRzJk/AQgA0HojJnK0uhEkAnbmszYsf477DV+LD02s ZEAlLGhJlf9qYaDiPMPwaZ3nK8/PYKzPpBWfHgRQP97rLHPIVJYl3BHDa/nWeZ2b e/HzYhpX0djbK9qe6W/CTfGbXmC/y+4dDGB8dvtTAW3JILm7xEdwiWtywozEVy7V lnMK4JQvlfOh+3XO6qv71FXyuRkObvkYzqvxUYHewtvvObcVxXHP0C0O6LB44iAW 2boZVVuiHdudnyNAezJajPMUT8SnI0bwL6+0TgnHL4cKNUEPQljIrrvi+9nCkq7V uBtnsYtyoo2reoxmCbX/Z1zZsxdUcKpeJHlc5AypyN8DUJ+APJ9NnwARAQABiQEl BBgBAgAPBQJRzJk/AhsMBQkJZgGAAAoJEHDdb8b0UJftOY0H/1TChmQrJC/qzefW PK7EqFlBg3TIEXdu8JHjF42ZOgzQRfp7E2wWzEx0Y45lNXMs6Yg15hWCEDaUDF6F 5WZKNrP8xIldyR9Aw7fyKqjZ9UuKovqofHsCiaSO7nWzGM6GF3nBDNI9NcFve/wN wggyjAbohOJrJGal3N0HlG3cakqjEmjBe1gQEMC0ZPlWstb/cqqr49TNPrRmQc4P SyGffh8Xqhw94m1LDBXFEaYe7AxjNk1sPAVfO1rOdLF6GOun/UwgbhDQX/Rb9C3t AhjSgyFEiR/gfrUZ7R6SY51qOUf1lN5ZN85C/x27XoZWYlsNaH3Ei6nG+yeswBMk ZRMbezQ= =Med3 -----END PGP PUBLIC KEY BLOCK-----

5 9

high amount of IOERRORs of closed ORconnections
by Toralf Förster 04 Dec '14

04 Dec '14

I still do wonder about the high percentage of IOERRORs of closed ORconnections (as seen in page 1#5 of the arm tool window, press e + q). May I ask here others about their experiences ? The issue is already filed in [1]. [2] contains a python script I used to monitor the issue directly (instead using arm). [1] https://trac.torproject.org/projects/tor/ticket/13603 [2] https://trac.torproject.org/projects/tor/ticket/13603#comment:10 -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E

1 0

Colocated relay pricing
by grarpamp 04 Dec '14

04 Dec '14

What are you seeing as prices to colocate, in terms of: 1RU - rent, power, etc IP's - a few (3, or up to a /29 ie 8-3=5) Bandwidth - In terms of $US/Mbit Colocation Country/State. Company.

3 2

Why isn't there an announcement of the new Tails?
by I 03 Dec '14

03 Dec '14

1 0

doc/HARDENING Draft
by Libertas 01 Dec '14

01 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I thought I'd share an initial draft of doc/HARDENING. Please share any opinions or contributions you have. This was written in a little more than an hour, so it's still a work in progress. However, in the spirit of prototyping before polishing, I thought I'd share early. Here's the relevant ticket: https://trac.torproject.org/projects/tor/ticket/13703 A specific topic of conversation is how much of the advice should be in the document itself as opposed to linked sources. It could also use more OS diversity. After reading it, you can probably guess which *nix flavors I'm familiar with. Enjoy, Libertas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUc7qtAAoJELxHvGCsI27NOwsP/1bP+g4W2y1NHefR5bd+5hwo V927TXzarNneNFxfhKJsVewVnU593Ex13iHv+WgA+XM39xiK8KkhpxOaw2IpahZp pIRCk4/XX78YaEc/K3ci2AsNGFVXPBX7nm4/VOZ5qiGfo+FVeipykweF1dF+X1Wc 1wr8Q9LWKoIab+klu/BG5nG5NtwICYslbgXMvNnapHuy0Xn1+fvBx3mW9teMkJ0N Npssiy7XUqJx1XpdYNJr4XI28aHOV2p4FeCdsAgaQ1OBkOvpzMd+fw2Yb3FOiX/l 5pNCPMXFsS/+OXp1qOFKDQoOb7fEP6mY4NqdSovuJU0oWdurnHVk/X3SidALfH/L vFPdTwpCJSMLuYO7HsLLiLx6LkDtrDZ2y9+tUfpqKGAN0upXrIi5GWsbUeLcCqwY UFYdSg1GHsWJz7fU6F1vDLpGsiXU5yVqgaxfP06+nZ/smRt5sA3nlMDCZJi3BDes k0+c4+tAPZ5Yt6kJ5b1GBgxQMokDqnLm/4pb/qlp0EzDfhWpA+Un2lGdvInrz1ds VsVvbq/LLuxYylC3hlF8pNxBVMdbXycWM1w/VHtDjPZFdo9AO4CJHXeShYQa2O0W cBXdU+O59wWoxiCuEfo0O2xaJw2UIRfxauQbcp/A0rg8FKU1c2QeP2t7y8VdVC1Y SgQNVCUKYPBMCywJw9PA =yY3r -----END PGP SIGNATURE-----

9 14