- tor-dev - lists.torproject.org

Syboa: gui desktop tor monitor
by Sean Robinson 17 Jul '14

17 Jul '14

This email is to announce the first public release of Syboa[1], a tor controller for monitoring a local daemon instance. My primary motivation for Syboa was to replace TorK, so it looks[2] more like TorK than Vidalia. Syboa is not ready for non-developer users[3]. But after seeing the "UX Idea - A controller inside TBB"[4] thread last week, I decided to not wait any longer. It handles 95% of my needs and about 60% of my wishes; it may not work for anyone else. Unfortunately, this is more of a "throw it over the garden wall" source release as I do not have time to work on Syboa for the remainder of the year. I do monitor the tor-dev mailing list or anyone can contact me directly with questions. [1] https://gitorious.org/syboa/syboa [2] https://gitorious.org/syboa/syboa/source/7082a822b97c723a19c5cbca4256db3500… [3] https://gitorious.org/syboa/syboa/source/7082a822b97c723a19c5cbca4256db3500… [4] https://lists.torproject.org/pipermail/tor-dev/2014-July/007117.html -- Sean

2 1

Looking for front-end web developers for network status websites Atlas and Globe
by Karsten Loesing 17 Jul '14

17 Jul '14

Hello front-end web developers, Philipp and I are looking for somebody to fork and extend one of the two main Tor network status websites: https://atlas.torproject.org/ or https://globe.torproject.org/ Here's some background: both the Atlas and the Globe website use the Onionoo service (https://onionoo.torproject.org/) as their data back-end and make that data accessible to mere humans. The Onionoo service is maintained by Karsten. Atlas was written by Arturo as proof-of-concept for the Onionoo service and later maintained (but not extended) by Philipp. Globe was forked from Atlas by Christian who improved and maintained it for half a year, but who unfortunately disappeared a couple of weeks ago. That leaves us with no actively maintained network status website, which is bad. Want to help out? Here's how: Globe has been criticized for having too much whitespace, which makes it less useful on smaller screens. But we hear that the web technology behind Globe is superior to the one behind Atlas (we're no front-end web experts, so we can't say for sure). A fine next step could be to fork Globe and tidy up its design to work better on smaller screens. And there are plenty of steps after that if you look through the tickets in the Globe and Atlas component of our bug tracker. Be sure to present your fork on this list early to get feedback. You can just run it on your own server for now. The long-term goal would be to have one or more people working on a new network status website to replace Atlas and Globe. We'd like to wait with that step until such a new website is maintained for a couple of weeks or even months though. And even then, we may keep Atlas and Globe running for a couple more months. But eventually, we'd like to shut them down in favor of an actively maintained website. Let us know if you're interested, and we're happy to provide more details and discuss ideas with you. All the best, Philipp and Karsten

1 0

Pluggable transports meeting not very likely this Friday
by George Kadianakis 16 Jul '14

16 Jul '14

Hello! It seems that many PT people (including me) won't be able to attend the scheduled PT meeting this Friday. For this reason, we are calling this meeting off. Feel free to lurk in IRC in any case. Maybe someone will want to talk PT with you even if there is no scheduled meeting :) Thanks and sorry for the disturbance!

1 0

Clarification on Alice connecting to Introduction Point
by Richard Dennis 15 Jul '14

15 Jul '14

Hi, i am currently building a tor client that will be able to connect to a hidden service, i just have a few questions about the RELAY_COMMAND_INTRODUCE1 cell once a circuit is established to one of Bob's introduction point and an incorrect RELAY_COMMAND_INTRODUCE1 is sent, what, if anything would be expected back For the PK_ ID, what information is needed for this, I have received a V2 descriptor, and see it says to use the service-key, is this the service key for the introduction point i have selected which was found by decrypting the descriptor, or permanent-key found in the non decrypted v2 descriptor and where would i find bobs public key Many Thanks Richard

1 0

I propose a kickstarter for Roger, Nick, or Paul to receive a free Tor tattoo of his choice
by Virgil Griffith 15 Jul '14

15 Jul '14

e.g. https://imgur.com/sZUKADG I will donate. -V

1 0

Revised Relay Descriptor Fields proposal
by Virgil Griffith 14 Jul '14

14 Jul '14

Filename: ExtraRelayDescriptorFields.txt Title: Adding new X- fields to relay descriptor Author: Virgil Griffith, Nick Mathewson Created: 2014-06-03 Status: Open 1. Motivation We wish to allow developers to build new applications atop relays. Towards this end, we wish to add the ability for users to specify arbitrary new key-value entries under the "X-" namespace. 2. Proposal Allow optional key-value lines in the relay's torrc file. These lines will be mirrored in the relay's descriptor which is then published in the directory consensus. For example: X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-favoritequote Be excellent to each other. Party on dudes! X-foo bar The value field must be printable ASCII (characters 32-126). The value must not under any condition contain a newline. The key may contain lowercase ASCII letters (a-z), digits, underscore, or dash. In regex, [-_0-9a-z]. There may need to be a maximum sum length of the X- entries. This is left to the developers. I propose a maximum sum length of 5 kilobytes. To mitigate the chance of a malformed torrc file, I additionally propose there be a schema for the relay descriptor, and if the relay descriptor fails to match the schema it errors to the user to change her torrc file. -V

6 6

What little-t-tor bridge features/issues we should address?
by George Kadianakis 14 Jul '14

14 Jul '14

Hello Roger and Nick, as far as I know, bridge support was hastily implemented in little-t-tor, and it does not support all the features we would like it to support. During the dev meeting roadmapping, we added a task about improving the bridge implementation in Tor. Some of the items in the task are: - Bridges should save bridge information to the state file (proposal 192) - Fix UpdateBridgesFromAuthority. - Obfsbridges should be able to hide their ORPort (#7349) Some of those items are more long-term than others. What other tasks would you like to see in there? We are looking for tasks mainly related to bridges themselves, and not PTs. Thanks!

4 3

Re: [tor-dev] :(
by vmon＠riseup.net 14 Jul '14

14 Jul '14

Interesting! It is not a fundamental error per say, if you are a server you can't handle more than some number of connections anyway (you can increase that if you are root), so the client need to wait. You need a ddos defence mechanism against that (e.g. iptables) independent of what kind of server you are running. However, I put a defence mechanism against a ST client being able to open too many connections on the client side barring it by this formula: min(8, and ceilling of (MAX - count)/no of circ) I wonder how does it get bypassed : chop.cc:722 // If we're the client and we had no target connection, try // reopening new connections. If we're the server, we have to // just twiddle our thumbs and hope the client does that. if (no_target_connection) { log_debug(this, "number of open connections on this circuit %u, golobally %u", (unsigned int)downstreams.size(), (unsigned int) conn_count()); if (config->mode != LSN_SIMPLE_SERVER && (int)downstreams.size() < min(MAX_CONN_PER_CIRCUIT, ((int)(MAX_GLOBAL_CONN_COUNT - conn_count() + (int)circuit_count() - 1)/(int)circuit_count()))) //min(8, and ceilling of (MAX - count)/no of circ) circuit_reopen_downstreams(this); If you start many ST clients though that won't be effective and you are basically ddosing the server. vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > 7477.6308 [debug] http_server_JS_transmit: SERVER found the applicable > HTTP response template with size 10399 > 7477.6324 [debug] conn_do_flush: <1102.35442> flushing 6349 bytes to > peer [enabled=6] > 7477.6324 [debug] send_targeted: <1102.35442> transmitted block 4 > <d=488 p=3 f=DAT> > T:7477.6324: ckt 1102 <ntp 5 outq 0>: send 4 <d=488 p=3 f=DAT> > 7477.6324 [debug] send_targeted: <1102> efficiency: 24.813380 > 7477.6325 [debug] downstream_flush_cb: <1102.35442> 0 bytes still to > transmit (reached EOF) (received EOF) > 7477.6326 [debug] drop_downstream: <1102> dropped connection > <1102.35442> to 127.0.0.1:51874, now 0 > 7477.6326 [debug] circuit_arm_axe_timer: <1102> axe after 1800000 > milliseconds > 7477.6326 [debug] close: <0.35442> closing connection; 736 remaining > 7477.6326 [debug] close_cleanup_cb: cleaning up 0 circuits and 1 > connections > 7477.6380 [info] server_listener_cb: 127.0.0.1:5000: new connection to > server from 127.0.0.1:51875 > 7477.6381 [debug] conn_create: <0.35443> new connection > 7477.6381 [debug] downstream_flush_cb: <0.35443> 0 bytes still to > transmit (no circuit) (never received) > 7477.6387 [debug] downstream_read_cb: <0.35443> 836 bytes available > 7477.6387 [debug] http_server_receive: <0.35443> SERVER received > request header of length 832 > 7477.6388 [debug] http_server_receive: Cookie: > 1o9Pt2B-kM=37XmMDPvsABcxKIT2I5nqNQOkkUKqhR7sAAAAFAT4AAAEAAAAAAAAAFgMBAQYQAAECAQAhhD7ExjZhmIiu2IaFGdGrT1arN52cDxVTXFe07egCZNbiKmf6yS9s9hRlJ489X2wZ5S7c00ORL9GU907NN3DqOG9EtcichBTz3V6MdLVVNxrCqWwMOiJIbCZ277f2pO; > F=QJ3or_CLfT-VVLEGeopox1nLiFoPjpMXXWmFMHl9OW4GQ49L5Z5Y8KNph2d8mQ3ViIjMzMPctvOzUoxcBhx2er_ > VIPfhqAh3s;ybTJK4VpoL=cH_avl8ZEIiw3Q_WZdqvCPF6EE;3Bqa=OFSbR36AqM3s7pr2N2e9Fv_ > IoJSQUvmnySI6bBC1VpTKXzv2hJ2W6P1hdRtxQrJmWWukBcWsKLUwFAMBAAEBFgMBACiF_LOpLxeA7Y1c; > n-5Sytb5R=2sQrFg4MK8c;Xz_=Z_ALz5YDp938ckzYjAAAAAA;AAAAAAA=AAAAAAAAA.. > > 7477.6389 [debug] transmit_soon: <0.35443> must send within 100 > milliseconds > 7477.6389 [debug] verify_and_extract: retrieved circ id 3075444694 > 7477.6389 [debug] recv_handshake: <0.35443> found circuit to > 127.0.0.1:5001 > 7477.6389 [debug] add_downstream: <1102> added connection <1102.35443> > to 127.0.0.1:51875, now 1 > 7477.6390 [debug] recv: <1102.35443> circuit to 127.0.0.1:5001 > 7477.6390 [debug] recv: <1102.35443> 350 bytes available > 7477.6390 [debug] recv: <1102.35443> receiving block 5 <d=318 p=0 > f=DAT r=0> > T:7477.6390: ckt 1102 <ntp 5 outq 0>: recv 5 <d=318 p=0 f=DAT r=0> > 7477.6391 [debug] recv: Data received: > 7477.6391 [debug] remove_next: next_to_process=5 data=0xe140740 op=DAT > 7477.6391 [debug] remove_next: next_to_process=6 data=(nil) op=XXX > 7477.6391 [debug] process_queue: <1102> processed 1 blocks > 7477.6392 [debug] upstream_flush_cb: <1102> 0 bytes still to transmit > 7477.6850 [debug] upstream_read_cb: <1102> 51 bytes available > 7477.6851 [debug] send: <1102> 51 bytes to send > 7477.6851 [debug] pick_connection: <1102> target block size 83 bytes > 7477.6851 [debug] pick_connection: <1102.35443> has been connected for > 0 secs > 7477.6851 [debug] transmit_room: <1102.35443> checking available > capacity for type 3 > 7477.6852 [debug] pick_connection: <1102.35443> offers 115 bytes > (http) > 7477.6852 [debug] pick_connection: <1102> no req: 9 avg des: > 712.111111 avg act: 663.333333 > 7477.6852 [debug] pick_connection: <1102> minabove 115 for > <1102.35443> maxbelow 0 for <1102.0> > 7477.6853 [debug] get_payload: contentType = 3, initTypePayload = 1, > typePayloadCount = 613 > 7477.6853 [debug] get_payload: first payload size=9647, best payload > size=3162, num candidate=100 > > 7477.6853 [debug] pick_appropriate_cover_payload: SERVER found the > next HTTP response template with size 3162 > 7477.6854 [debug] http_server_transmit: coping body of 3014 size > 7477.6854 [debug] http_server_transmit: SERVER embeding data1 with > length 83 into type 3 > 7477.6857 [debug] http_server_transmit: SERVER FileSteg sends resp > with hdr len 148 body len 106 > 7477.6858 [debug] conn_do_flush: <1102.35443> flushing 3309 bytes to > peer [enabled=6] > 7477.6858 [debug] send_targeted: <1102.35443> transmitted block 5 > <d=51 p=0 f=DAT> > T:7477.6858: ckt 1102 <ntp 6 outq 0>: send 5 <d=51 p=0 f=DAT> > 7477.6858 [debug] send_targeted: <1102> efficiency: 24.809808 > 7477.6859 [debug] downstream_flush_cb: <1102.35443> 0 bytes still to > transmit (reached EOF) (received EOF) > 7477.6860 [debug] drop_downstream: <1102> dropped connection > <1102.35443> to 127.0.0.1:51875, now 0 > 7477.6860 [debug] circuit_arm_axe_timer: <1102> axe after 1800000 > milliseconds > 7477.6860 [debug] close: <0.35443> closing connection; 736 remaining > 7477.6860 [debug] close_cleanup_cb: cleaning up 0 circuits and 1 > connections > 7477.7882 [info] server_listener_cb: 127.0.0.1:5000: new connection to > server from 127.0.0.1:51876 > 7477.7882 [debug] conn_create: <0.35444> new connection > 7477.7883 [debug] downstream_flush_cb: <0.35444> 0 bytes still to > transmit (no circuit) (never received) > 7477.7890 [debug] downstream_read_cb: <0.35444> 425 bytes available > 7477.7891 [debug] http_server_receive: <0.35444> SERVER received > request header of length 421 > 7477.7891 [debug] http_server_receive: Cookie: > 1o9Pt0=f_eWs3tuUJLpu8g2aiE1m2BwMF6jib99twQLIAAAAGAAAAAQEAAAAA;AAAAAAAAA=A; > AAAAAAAAA=AAAAAAAA. > > 7477.7891 [debug] transmit_soon: <0.35444> must send within 100 > milliseconds > 7477.7892 [debug] verify_and_extract: retrieved circ id 3075444694 > 7477.7892 [debug] recv_handshake: <0.35444> found circuit to > 127.0.0.1:5001 > 7477.7892 [debug] add_downstream: <1102> added connection <1102.35444> > to 127.0.0.1:51876, now 1 > 7477.7892 [debug] recv: <1102.35444> circuit to 127.0.0.1:5001 > 7477.7893 [debug] recv: <1102.35444> 33 bytes available > 7477.7893 [debug] recv: <1102.35444> receiving block 6 <d=0 p=1 f=DAT > r=0> > T:7477.7893: ckt 1102 <ntp 6 outq 0>: recv 6 <d=0 p=1 f=DAT r=0> > 7477.7893 [debug] remove_next: next_to_process=6 data=0xe1683d0 op=DAT > 7477.7893 [debug] remove_next: next_to_process=7 data=(nil) op=XXX > 7477.7894 [debug] process_queue: <1102> processed 1 blocks > lliseconds > 7477.8125 [debug] verify_and_extract: retrieved circ id 4060828808 > 7477.8125 [debug] circuit_create: <1103> new circuit > 7477.8125 [info] circuit_open_upstream: <1103> trying to connect to > 127.0.0.1:5001 > 7477.8126 [info] circuit_open_upstream: <1103> connection to > 127.0.0.1:5001 failed: Too many open files7477.8047 [info] > server_listener_cb: 127.0.0.1:5000: new connection to server from > 127.0.0.1:51877 > 7477.8048 [debug] conn_create: <0.35445> new connection > [warn] Error from accept() call: Too many open files > 7477.8048 [debug] downstream_flush_cb: <0.35445> 0 bytes still to > transmit (no circuit) (never received) > 7477.8054 [debug] downstream_read_cb: <0.35445> 506 bytes available > 7477.8054 [debug] http_server_receive: <0.35445> SERVER received > request header of length 502 > 7477.8054 [debug] http_server_receive: Cookie: > 1o9=Pt6QwYewJ9F6kjH;fGyxKq9Ti=cPKqah0wQFhNNL-wAAAAHAB0ABwEAAAAA;AA=AAFQMBABjR- > 87YPxS9nJMDyQOhg3303;SW3kO=0Q03gAAAAAAA;AAA=AAAAAAAA;AAAAAA=AAAA;AAA=.. > > 7477.8055 [debug] transmit_soon: <0.35445> must send within 100 > milliseconds > 7477.8055 [debug] verify_and_extract: retrieved circ id 3075444694 > 7477.8055 [debug] recv_handshake: <0.35445> found circuit to > 127.0.0.1:5001 > 7477.8056 [debug] add_downstream: <1102> added connection <1102.35445> > to 127.0.0.1:51877, now 2 > 7477.8056 [debug] recv: <1102.35445> circuit to 127.0.0.1:5001 > 7477.8056 [debug] recv: <1102.35445> 68 bytes available > 7477.8056 [debug] recv: <1102.35445> receiving block 7 <d=29 p=7 f=DAT > r=0> > T:7477.8057: ckt 1102 <ntp 7 outq 0>: recv 7 <d=29 p=7 f=DAT r=0> > 7477.8057 [debug] recv: Data received: > 7477.8057 [debug] remove_next: next_to_process=7 data=0xe1683d0 op=DAT > 7477.8057 [debug] remove_next: next_to_process=8 data=(nil) op=XXX > 7477.8058 [debug] process_queue: <1102> processed 1 blocks > 7477.8058 [debug] upstream_flush_cb: <1102> 0 bytes still to transmit > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > 7477.8095 [info] upstream_event_cb: <1102> EOF from upstream > 7477.8095 [debug] send: <1102> 0 bytes to send > 7477.8095 [debug] pick_connection: <1102> target block size 32 bytes > 7477.8095 [debug] pick_connection: <1102.35444> has been connected for > 0 secs > 7477.8096 [debug] transmit_room: <1102.35444> checking available > capacity for type 5 > 7477.8096 [debug] pick_connection: <1102.35444> offers 65 bytes (http) > 7477.8096 [debug] pick_connection: <1102> no req: 10 avg des: > 647.300000 avg act: 603.500000 > 7477.8097 [debug] pick_connection: <1102.35445> has been connected for > 0 secs > 7477.8097 [debug] transmit_room: <1102.35445> checking available > capacity for type 5 > 7477.8097 [debug] pick_connection: <1102.35445> offers 71 bytes (http) > 7477.8097 [debug] pick_connection: <1102> no req: 11 avg des: > 594.272727 avg act: 555.090909 > 7477.8098 [debug] pick_connection: <1102> minabove 65 for <1102.35444> > maxbelow 0 for <1102.0> > 7477.8098 [debug] http_server_JS_transmit: sbuflen = 33 > > 7477.8098 [debug] get_payload: contentType = 5, initTypePayload = 1, > typePayloadCount = 1548 > 7477.8099 [debug] get_payload: first payload size=46676, best payload > size=20041, num candidate=100 > > 7477.8099 [debug] http_server_JS_transmit: SERVER found the applicable > HTTP response template with size 20041 > 7477.8119 [debug] conn_do_flush: <1102.35444> flushing 8060 bytes to > peer [enabled=6] > 7477.8119 [debug] send_targeted: <1102.35444> transmitted block 6 <d=0 > p=1 f=FIN> > T:7477.8119: ckt 1102 <ntp 8 outq 0>: send 6 <d=0 p=1 f=FIN> > 7477.8119 [debug] send_targeted: <1102> efficiency: 24.809808 > 7477.8120 [debug] send: <1102> 1 dead cycles > [warn] Error from accept() call: Too many open files > 7477.8121 [debug] downstream_flush_cb: <1102.35444> 0 bytes still to > transmit (reached EOF) (received EOF) > 7477.8121 [debug] drop_downstream: <1102> dropped connection > <1102.35444> to 127.0.0.1:51876, now 1 > 7477.8121 [debug] close: <0.35444> closing connection; 737 remaining > 7477.8122 [debug] close_cleanup_cb: cleaning up 0 circuits and 1 > connections > 7477.8123 [info] server_listener_cb: 127.0.0.1:5000: new connection to > server from 127.0.0.1:51879 > 7477.8123 [debug] conn_create: <0.35446> new connection > [warn] Error from accept() call: Too many open files > [warn] Error from accept() call: Too many open files > 7477.8124 [debug] downstream_read_cb: <0.35446> 443 bytes available > 7477.8124 [debug] http_server_receive: <0.35446> SERVER received > request header of length 439 > 7477.8124 [debug] http_server_receive: Cookie: > iFQ=L8srwNz_kQgBW4weYMYT;sLEmEhA8VZ=9NBYIXNQa0AAAAAAAAA;A=AEAAAAAA;A=AA; > AAAAAAAAAA=AAAAA;AAA=AAAA.. > > 7477.8125 [debug] transmit_soon: <0.35446> must send within 100 mi

2 1

[patch] properly test for OPENSSL_NO_COMP
by Pascal Stumpf 14 Jul '14

14 Jul '14

LibreSSL has removed compression support. Tor should check for the OPENSSL_NO_COMP define before trying to disable compression at runtime. diff --git a/src/common/tortls.c b/src/common/tortls.c index e06a2ae..0f98968 100644 --- a/src/common/tortls.c +++ b/src/common/tortls.c @@ -1314,10 +1314,12 @@ tor_tls_context_new(crypto_pk_t *identity, unsigned int key_lifetime, SSL_CTX_set_options(result->ctx, SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION); } +#ifndef OPENSSL_NO_COMP /* Don't actually allow compression; it uses ram and time, but the data * we transmit is all encrypted anyway. */ if (result->ctx->comp_methods) result->ctx->comp_methods = NULL; +#endif #ifdef SSL_MODE_RELEASE_BUFFERS SSL_CTX_set_mode(result->ctx, SSL_MODE_RELEASE_BUFFERS); #endif

3 4

Re: [tor-dev] Using ScrambleSuit with something other than Tor
by Philipp Winter 11 Jul '14

11 Jul '14

Hi Yuhao, On Fri, Jul 11, 2014 at 08:20:25PM +0800, Yuhao Dong wrote: > I'm Yuhao Dong (undergrad student at University of Waterloo) and I'm > currently doing research on, surprise, my own traffic obfuscation > system. Cool! I'm in Toronto until the middle of August -- in case you are back until then and want to meet up in person. > I'd like to compare it to ScrambleSuit; however I am > currently on break in China. It is going to be really hard to set up > Tor in a way that works; besides, I am using a test suite that > transmits specially-shaped traffic over HTTP. I would like to be > able to see what happens if I apply ScrambleSuit to that traffic > instead of Tor. That sounds good. Given Tor's high variance in latency and throughput, it's more effective to compare the performance of pluggable transports without Tor, in a LAN setting. > Is there a way to build a generic ScrambleSuit SOCKS5 proxy? In > other words, it would be awesome if I could set up two servers on my > LAN: > > web browsing client <-SOCKS-> first LAN server <-ScrambleSuit-> > second LAN server <-> Internet > > so that arbitrary traffic can be tunneled through ScrambleSuit, and > I can do packet analysis on the ScrambleSuit link. > > I understand that Tor's "pluggable transport" system uses SOCKS5 > underneath; however the spec seems very vague on how to precisely > get that local SOCKS5 address. How can I use ScrambleSuit in the way > I described, to encapsulate something other than Tor? It sounds like you basically want to have obfsproxy with ScrambleSuit on both your LAN servers. The first LAN server could be started like this: python /path/to/obfsproxy \ --log-min-severity=debug \ --data-dir=/tmp/scramblesuit-client \ scramblesuit \ --password=BANANASAPPLESCOCONUTSPEACHESEGGS \ --dest SECOND_LAN_SERVER:50000 \ client 0.0.0.0:1080 The second LAN server could be started like this: python /path/to/obfsproxy \ --log-min-severity=debug \ --data-dir=/tmp/scramblesuit-server \ scramblesuit \ --password=BANANASAPPLESCOCONUTSPEACHESEGGS \ --dest SOCKS_PROXY:1234 \ server 0.0.0.0:50000 SOCKS_PROXY can be Tor or an arbitrary SOCKS proxy which allows direct connections to your Internet link. You can then configure arbitrary applications to use the SOCKS5 proxy running on your first LAN server. Hope that helps, Philipp

1 0