Re: [tor-dev] Preferred OpenSSL config for Tor?
On Tue, Sep 16, 2014 at 11:08 AM, Steve Snyder wrote: > What are the recommended build options for OpenSSL 1.0.1x when building it > for use with Tor v0.2.5.x? Assuming you're on an x86-64 machine and have a reasonably recent GCC (4.6 should do), as a starting point, this is how I build OpenSSL for the CMU Tor exit: ./Configure linux-x86_64 \ --prefix=/root/tor/ssl \ no-shared no-gost enable-ec_nistp_64_gcc_128 \ '-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -Wl,-z,relro' Replace 'linux' with your OS of choice. It can almost certainly be tuned further. The only thing I know for sure you really want is 'enable-ec_nistp_64_gcc_128', which (if your hardware and compiler support it) dramatically increases your throughput. GOST is disabled not to reduce footprint but because the build failed with it on, and shared libraries are disabled because I link the Tor binary statically. The last line is almost entirely about compile-time stack hardening. You must have '-O2 -fPIC' in there or the subsequent Tor build will fail; everything else is optional-but-a-good-idea-IMNSHO. zw ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Preferred OpenSSL config for Tor?
What are the recommended build options for OpenSSL 1.0.1x when building it for use with Tor v0.2.5.x? Put another way, what default OpenSSL features (ciphers, etc.) should be disabled and what optional features should be enabled? My goal here is to build a Tor-oriented OpenSSL, one that dispenses with features Tor doesn't need/use while enabling those that improve security and/or performance. Thanks. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Guardiness: Yet another external dirauth script
> - Q: Why do you slow stem instead of parsing consensuses with Python on your > own? > > This is another part where I might have taken the wrong design > decision, but I decided to not get into the consensus parsing business > and just rely on stem. > > This is also because I was hoping to use stem to verify consensus > signatures. However, now that we might use Daniel's patch to populate > our consensus database, maybe we don't need to treat consensuses as > untrusted anymore. > > If you think that I should try to parse the consensuses on my own, > please tell me and I will give it a try. Maybe it will be > fast. Definitely not as fast as summary files, but maybe we can parse > 3 months worth of consesuses in 15 to 40 seconds. I'm not sure why you think it was the wrong choice. If Stem isn't providing you the performance you want then seems like speeding it up is the right option rather than writing your own parser. That is, of course, unless you're looking for something highly specialized in which case have fun. Nick improved parsing performance by around 30% in response to this... https://trac.torproject.org/projects/tor/ticket/12859 Between that and turning off validation I'd be a little curious where the time is going if it's still too slow for you. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Guardiness: Yet another external dirauth script
On 16 Sep 2014, at 16:15, George Kadianakis wrote: > How guardiness works > The idea was that the guardiness script will be an external script > that is run by Tor in a similar fashion to the bandwidth auth > scripts. We chose that because we could write the script in a > high-level language and because it could be modular and we could > change the algorithm in the future if we wanted. Unfortunately, it > seems that external scripts in dirauths are a PITA to maintain as can > be seen by the lack of bwauth operators. The problem isn't so much that this is an external script, the problem is that there are never dedicated maintainers for these things (tho it being an external script is additionally problematic). If they are in Tor proper, we have someone who cares about them when new stuff gets introduced, and it gets updated with the rest of Tor, etc. > Summary files are designed to be quick to parse (even with Python) and > contain all the necessary information for guardiness. For example, > parsing 2000 summary files in my laptop takes about 10 seconds. Does this scale linearly? 9 months would be ~6500 files. > FWIW, the guardiness scripts are ready for review and can be found here: > https://gitweb.torproject.org/user/asn/hax.git/shortlog/refs/heads/guardiness > > How the guardiness script will be deployed > > The idea is that dirauths will add another script to their crontab > that is called every hour (before or after the bwauth scripts). Only 4/9 have such scripts, if at all - it is possible to run a bwauth on a different host, and scp the file over. I don't know if any of the dirauth ops actually do this currently. > The script first calls the summarizer script, which goes to the > consensus/ directory and summarizes all consensuses it finds and puts > them in the summary/ directory. The summarizer script then deletes all > the consensuses that got summarized. You must not delete files which you did not create. It's not cool to delete consensuses which tor decided to put somewhere if you're not tor. This is relevant to the plan to use mvdan's script. > Then the script calls the the guardiness script, which goes to the > summary/ directory, parses all summary files it finds, and outputs a > guardiness output file that gets parsed by the dirauth prior to voting. > > That should be all. Easy, eh? :) What are the failure modes? Are there version strings included, does Tor notice if the guardiness file is outdated, etc? What happens when different dirauths use different versions of the guardiness file generation script? Cheers Sebastian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Guardiness: Yet another external dirauth script
==Guardiness: Yet another external dirauth script== Introduction One well-known problem with Tor relays, is that Guards will suffer a big loss of traffic as soon as they get the Guard flag. This happens because clients pick guards every 2-3 months, so young guards will not get picked by old clients and mainly attract new clients. This is documented in 'phase three' of Roger's blog post: https://blog.torproject.org/blog/lifecycle-of-a-new-relay The problem gets even worse if we extend the guard lifetime to 8-9 months. The plan to solve this problem is to make client load balancing a bit smarter by priotizing guards that suffer this traffic loss as middle relays. The reason I'm sending this email is because this feature is by far the trickiest part of prop236 (guard node security) and I wanted to inform all dirauths of our plan and ask for feedback on the deployment procedure. How guardiness works Authorities calculate for each relay how many consensuses it has been a guard for the past 2-3 months, and then they note that fraction down in the consensus. Then clients parse the consensus and if they see a guard that has been a guard for 55% of the past consensuses, they will consider that relay as 55% guard and 45% non-guard (that's 100% - 55%). You can find more information at: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/236-single-guard-node.txt#l101 The idea was that the guardiness script will be an external script that is run by Tor in a similar fashion to the bandwidth auth scripts. We chose that because we could write the script in a high-level language and because it could be modular and we could change the algorithm in the future if we wanted. Unfortunately, it seems that external scripts in dirauths are a PITA to maintain as can be seen by the lack of bwauth operators. How the guardiness script works The guardiness script, is supposed to parse 2-3 months worth of consensuses (but should also be to do the same for 9 months worth of consensuses) and calculate the guard fraction of each guard, save it to a file, and have the dirauth read it to update its routerstatuses. One problem I encountered from early on, is that stem takes about 30mins to parse 3 months of consesuses (~2000 consensuses). Since this script should ideally be run every hour before each authority votes, such long parsing time is unacceptable. I mentioned this problem at https://trac.torproject.org/projects/tor/ticket/9321#comment:19 and stated a few possible solutions. I received some feedback from Nick, and the solution I decided to take in the end is to have another script that is called first and summarizes consensuses to summary files. Summary files are then saved to disk, and parsed by the guardiness script to produce an output file that is read by dirauths. Summary files are designed to be quick to parse (even with Python) and contain all the necessary information for guardiness. For example, parsing 2000 summary files in my laptop takes about 10 seconds. FWIW, the guardiness scripts are ready for review and can be found here: https://gitweb.torproject.org/user/asn/hax.git/shortlog/refs/heads/guardiness How the guardiness script will be deployed The idea is that dirauths will add another script to their crontab that is called every hour (before or after the bwauth scripts). The script first calls the summarizer script, which goes to the consensus/ directory and summarizes all consensuses it finds and puts them in the summary/ directory. The summarizer script then deletes all the consensuses that got summarized. Then the script calls the the guardiness script, which goes to the summary/ directory, parses all summary files it finds, and outputs a guardiness output file that gets parsed by the dirauth prior to voting. That should be all. Easy, eh? :) Now I will start a FAQ section where I state my doubts and fears. FAQ - Q: Where do dirauths find all those old consensuses? There are various ways for dirauths to populate their consensus/ directory. They could fetch consensuses from metrics, or they could add a cron job that copies cached-consensus to a directory every hour. However, I think the cleanest solution is to use Daniel MartÃ's upcoming consensus diff changes. Daniel will add a torrc option that allows Tor to save consensuses to a directory. My idea was to get dirauths to use Daniel's code to populate their consensus/ directory for two or three months. And then, after two or three months enable the guardiness scripts. To make sure that this is indeed the best approach, I need to learn from Nick when he plans to merge Daniel's code to Tor. - Q: How does guardiness look like in the consensus? Here is how a guard with guardiness (GuardFraction) 10% looks like in the consensus: r test006r HyS1DRHzEojbQVPZ1B3zAHc/HY0 9St4yWfV4huz5V86mt24HL3Yi2I 2014-09-06 13:44:28 127.0.0.1 5006 7006 s Exit Fast Guard HSDir Running Stable V2Dir Valid v
Re: [tor-dev] Call for a big fast bridge (to be the meek backend)
On 16/09/14 03:12, David Fifield wrote: > The meek pluggable transport is currently running on the bridge I run, > which also happens to be the backend bridge for flash proxy. I'd like to > move it to a fast relay run by an experienced operator. I want to do > this both to diffuse trust, so that I don't run all the infrastructure, > and because my bridge is not especially fast and I'm not especially > adept at performance tuning. > > All you will need to do is run the meek-server program, add some lines > to your torrc, and update the software when I ask you to. The more CPU, > memory, and bandwidth you have, the better, though at this point usage > is low enough that you won't even notice it if you are already running a > fast relay. I think it will help if your bridge is located in the U.S., > because that reduces latency from Google App Engine. > > The meek-server plugin is basically just a little web server: > https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek-server > > Since meek works differently than obfs3, for example, it doesn't help us > to have hundreds of medium-fast bridges. We need one (or maybe two or > three) big fat fast relays, because all the traffic that is bounced > through App Engine or Amazon will be pointed at it. > > My PGP key is at https://www.bamsoftware.com/david/david.asc if you want > to talk about it. > As an extension, how about putting multiple bridges behind the reflector? Tor does not yet pass the bridge fingerprint to PTs, but we could hack it up along the lines of: Bridge meek 0.0.2.0:1 $FINGERPRINT1 fpr=$FINGERPRINT1 url=https://meek-reflect.appspot.com/ front=www.google.com Bridge meek 0.0.2.0:1 $FINGERPRINT2 fpr=$FINGERPRINT2 url=https://meek-reflect.appspot.com/ front=www.google.com meek-client would pass fpr to the reflector, who would select the bridge it connects the client to. (This is basically what I have in mind for #10196 for flashproxy.) X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Transparent Proxy: how does it work?
Hello dear torrorists :) I'm wanting to do some weird things with iptables in order to force some connections through Tor's TransProxy, but before that I have an interrogation on its internals: How does it detect if we're wanting to use, let's say, SMTP over Tor? Is there any kind of sniffer that tells tor "ok, so this one wants to go to mail.google.com:25, this other one to www.ethack.org:443 with SSL" ? If so, how does it work? It seems it may cause some problems when using Tor on a gateway, like some android device with tethering: forcing tethered connections through tor [orbot] seems to be really hard. Thank you in advance for your enlightenment. Cheers, C. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
