- tor-dev - lists.torproject.org

Hidden services mailing list
by Michael Rogers 20 Jul '14

20 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, Several projects use Tor hidden services for peer-to-peer communication, including TorChat, TORFone, Ricochet, Ploggy, OnionShare, Invisible.im, Ciboulette and Briar. I suspect many of us are running into similar issues because the hidden service protocol and implementation were designed for hidden services that behave like servers rather than clients, i.e. that have long uptime and stable network connections. I've created a mailing list to discuss these issues. If you're interested in participating, you can join the list here: https://fulpool.org/cgi-bin/mailman/listinfo/hidden-services Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJTy9lOAAoJEBEET9GfxSfMZMIH/jHmO6/RlLUDSaEcxtgSsO1W rlxW9oPCmwoFg258+1FRAVmfpqmUxmr0RTMiG4yb2Go23mM7HmnNVJz0mRXJsMxA 1Bu9cEUlROYDL1SEMoc8Apt6ymZUTOxknYIrXRsNJlfEPCmte9Vf8i8xjZJna6cr QpL+/1C/NmD8synteIJvHTCu1pa4MMHlLfjawSJzavaP2dMK/IVz12XDrdBx8zQU GNUt/FanZ5Cc8AUQHsd/+eC2ey24yg3iMH/yhgaU1zdG05T2wcyXjOVe70cHo6Lk Z3aaXaXg9tyISXuTCQXNjdrurwv9MlTjwvOZt6sGbOOvxHKh0S0N9X8txfEusJ8= =uOE9 -----END PGP SIGNATURE-----

1 0

GSOC Pluggable Transport Combiner (FOG) Status Update 4
by quinn jarrell 19 Jul '14

19 Jul '14

Hi everyone, These past two weeks I've worked on - Renamed the project to fog - The fog client can now launch multiple chains. It checks all the requested combined pt chains and gets the unique set of them. So it only launches one instance of each pt to reduce redundancy. Also each chain is launched when its pts are ready instead of waiting for all the pts to be ready. - Fixed #12613 <https://trac.torproject.org/projects/tor/ticket/12613> - Fixed parsing ClientTransportPlugin lines with multiple pt methods launched by one pt

1 0

[GSoC 2014] Revamp GetTor status report #4
by Israel Leiva 19 Jul '14

19 Jul '14

Hi all! This is my fourth status update for the Revamp GetTor GSoC project. I'll summarize what I've done. If you have any doubts/comments please tell me. Progress: [*] Fixed pending issue on the dropbox module: Add fingerprint of key that signed the bundles. This had me stuck for a while, mainly because a misconception I had about signatures. [*] Minor modifications in the Core module. [*] SMTP module almost complete: it can successfully process an email, figure out what is asking (links for certain OS, help) and in what language. It sends back a reply in that language. There are some error checks pending. Unfortunately, I couldn't test the above on a real mail server, but the process to do so is pretty straightforwar, so it shouldn't mean trouble. For now it shows replies on screen. [*] Created basic .po files for the messages sent via the SMTP module. Sample versions available in english and spanish. Goals until next bi-weekly report: [+] Add proper error checking on SMTP module, as well as to try to avoid code reuse between the Core and SMTP modules. [+] Work on possibly-definitive replies (.po files). [+] Have a functional XMPP module. As always, you can check what's been done on https://github.com/ileiva/gettor/tree/master/src Have a nice weekend! Best, -- israel

1 0

Orbot & Orfox - GSoC bi-weekly report 4
by Amogh Pradeep 18 Jul '14

18 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Status Report 4 July 18th, 2014. Things I am working on: 1)Setting up repos and building: After having built fennec, we have now started to try to get it built on the jenkins server. Hopefully we will be successful and will be able to push out a version of the browser soon. 2)DNS leak plugging: According to dnsleaktest.com , there seems to be a dnsleak in the current fennec browser that we've made, working on trying to plug this. Suggestions welcome! More things to come: - - Will continue to look for leaks and more testing. - - Work on plugging the dns leak. - - Stripping out not required parts of the fennec browser. Some parts like sync won't be required and hence will be removed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyPoOAAoJELm/SSKdtjUk1P0IAImh1pMn21W31p0mW+ENbOTu 9QKapoIEyaHYKuM7/Wf4sdPrsgD+7bEHdH7cEvJ1SePBv3xdjXWTofz//6Kwns5r e4f0Szi8FxobtCZgwh9BfUrNYi7rnVc2tn+0mr6XT9meJ3HR4Ob2Sybi58zTmNxV 1G+ZVNas/3Hd5Xd3/aKmRwKmJUvw7ZACRHDxSqXx55i1uqQIMs+hcGjFXagcwp2o hvJngebJgRv92uurVscZP2M71PHVtOPNOxAZvgqUP4Mm7TXP0P4JJbXrBdhBvmbW OxuQB0kvfEVZ+1FpCOQw1qy7qNZV9QUC8bvFy15h/JaaS0mZ48t5AXlEtTEhPEY= =KcQ2 -----END PGP SIGNATURE-----

3 2

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

SENDME cells
by Gareth Owen 09 Jul '14

09 Jul '14

(sorry re-post - forgot subject) Dear all I'm working on a tor research project and am having difficulty understanding the SENDME cells. The tor spec acknowledges that it isn't particularly clear so I would welcome some clarification please. The spec says that *all* nodes in a circuit maintain a send and receive window, and that this window is decremented on each RELAY_DATA and incremented on each SENDME. Cells that are neither of these do not affect the window size. The problem I have understanding is, that only edge nodes will know whether a cell is a RELAY_DATA, the intermediate nodes only know that its a RELAY but not what type. So, if only RELAY_DATA decrements the window size, and intermediate nodes cannot spot these, what point is there in intermediate nodes having a window? Any help greatly appreciated. Gareth --- Dr Gareth Owen Senior Lecturer School of Computing, University of Portsmouth W: ghowen.me

3 4

(Extra) roadmapping PT meeting this Friday (16:00UTC 11th of July 2014)
by George Kadianakis 08 Jul '14

08 Jul '14

Hello friends, the PT meeting last week was a bit quiet because it was conflicting with the Tor dev meeting. To compensate for that, we are thinking of throwing an extra PT meeting this Friday. The agenda can be modified according to the participants, but we are planning to spend some time writing down the fictional roadmap designed during the dev meeting to a wiki page, so that we can better plan PT development in the months ahead If you are in a roadmapping mood, feel free to pass by and help. As always, the meeting is going to occur at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Cheers!

1 0

Re: [tor-dev] [HTTPS-Everywhere] [GSoC] HTTPS Everywhere secure ruleset update mechanism update
by Yan Zhu 08 Jul '14

08 Jul '14

(resending to tor-dev with tp.o email address) On 07/08/2014 03:42 AM, Yan Zhu wrote: > On 07/08/2014 12:07 AM, Jeroen Massar wrote: >> On 2014-07-07 20:40, Red wrote: >> [.. lots of cool work being worked on ..] >> >> Hi Zack, >> >> Seems you are doing lots of cool stuff ;) >> >> But I am one of those strange people who really hate it that every >> separate tool has their own updater (which can be used for tracking a >> user, as the set of updater tools polling servers makes a fingerprint in >> the same way other flows make a fingerprint). > > Hi Jeroen, > > This makes a lot of sense. I'm aware of the fingerprintability concern, > and EFF tech projects generally try to mitigate it by polling the update > servers at randomized intervals over fresh Tor circuits if possible. For > this project, we initially proposed polling for an update when the > browser starts and every 3 hours plus some random, evenly-distributed > number of milliseconds between 0 and 300000. I'm curious if others have > more refined suggestions! > >> >> And thus I run Little Snitch and block those updates. Till I deem it a >> good time for the update to be done and trigger it manually. >> >> As such, when you get to the stage of adding features, it would be good >> if there was: >> - an option to disable the auto fetching > > Yes, this would be fairly easy to add. > >> - an option to trigger the fetching > > Probably also easy. > >> - to feed the update mechanism with a pre-fetched file >> (eg provided through a different update mechanism) > > Since the update mechanism is just an XHR that downloads a new ruleset > library from a hardcoded static URL and replaces the existing one in the > Firefox profile directory, you could fetch-and-replace this manually via > any number of mechanisms. :) > > Also, the ruleset libraries will still ship with extension updates, so > you could disable ruleset updates and just wait for the next HTTPS > Everywhere release. > > -Yan > >> >> Greets, >> Jeroen >> >> _______________________________________________ >> tor-dev mailing list >> tor-dev(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >> > > > > > _______________________________________________ > HTTPS-Everywhere mailing list > HTTPS-Everywhere(a)lists.eff.org > https://lists.eff.org/mailman/listinfo/https-everywhere > -- Yan Zhu <yan(a)eff.org>, <yan(a)torproject.org> Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134

2 1

Re: [tor-dev] [HTTPS-Everywhere] [GSoC] HTTPS Everywhere secure ruleset update mechanism update
by Yan Zhu 08 Jul '14

08 Jul '14

(resending to tor-dev with tp.o email address) On 07/08/2014 03:30 AM, Yan Zhu wrote: > On 07/08/2014 02:55 AM, Ben Laurie wrote: >> On 7 July 2014 19:40, Red <redwire(a)riseup.net> wrote: >>> Despite the fact that the process for producing the signature in >>> question[2] seemed to work fine- Openssl was able to generate and verify >>> the signature, the testing code calling the verifyData[3] function used >>> for verification was returning an undocumented NS_ERROR_FAILURE >>> exception. I had spent a great deal of time asking for support in >>> relevant Firefox extension development IRC channels, reading source code >>> from unit tests for the nsIDataSignatureVerifier component, and >>> experimenting with alternative openssl commands in order to try to >>> figure out why this error was occurring. >> >> Looking at the pk1sign source, it looks like the signature needs to be >> in base64. Was that what you were using? >> >> Do you have a test case that fails using command line tools? > > I think Zack's original failing test case was generated via something like: > $ openssl rsautl -sign -in update.digest -out signtmp.sig -inkey privkey.pem > $ openssl base64 -in signtmp.sig -out update.json.sig > > as described in the original spec that we wrote: > https://github.com/redwire/https-everywhere/blob/makeJSONManifest/doc/updat… > > Here is the diff between the failing test and the passing test: > https://github.com/redwire/https-everywhere/commit/8b3c85d9d90d679e8b699701…. > I generated the data for the passing test with pk1sign. > > The documentation for nsIDataSignatureVerifier does not really describe > the expected data format for the signature [1], so it took a while to > figure out that it expects a very specialized form [2]. > > [1] > https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Inter… > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=685852#c0 > > >> _______________________________________________ >> tor-dev mailing list >> tor-dev(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >> > > > > > _______________________________________________ > HTTPS-Everywhere mailing list > HTTPS-Everywhere(a)lists.eff.org > https://lists.eff.org/mailman/listinfo/https-everywhere > -- Yan Zhu <yan(a)eff.org>, <yan(a)torproject.org> Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134

1 0

[GSoC] HTTPS Everywhere secure ruleset update mechanism update
by Red 08 Jul '14

08 Jul '14

Hello everyone, I would like to quickly summarize what has been going on for the last couple of weeks of my work. Due to my mentor, Yan, being away on travel, we haven't had time to have a formal weekly meeting on IRC as per usual. We have, however, been emailing on the HTTPS Everywhere mailing list frequently to discuss some of the problems I've been working on last week. We have also compiled a list of things I am to work on for the next week, which I will summarize here. For the past week, I have been grappling with a problem pertaining to digital signature verification using the nsIDataSignatureVerifier XPCOM component designed to handle this task. I had written a few tests[1] that would use the testing mechanism that Yan built to make sure that the hashing and signature verification my project would rely on for security was working. The testing mechanism was built after our last meeting the Friday before last, during which time we realized we could write a separate Firefox extension using the addon SDK (and thus, Jetpack's testing suite) and import the HTTPS Everywhere component into that extension for testing purposes. Despite the fact that the process for producing the signature in question[2] seemed to work fine- Openssl was able to generate and verify the signature, the testing code calling the verifyData[3] function used for verification was returning an undocumented NS_ERROR_FAILURE exception. I had spent a great deal of time asking for support in relevant Firefox extension development IRC channels, reading source code from unit tests for the nsIDataSignatureVerifier component, and experimenting with alternative openssl commands in order to try to figure out why this error was occurring. Yan was able to get the test to pass by generating a key and signature using the NSS tools. However, she has said that this process is more involved than we would like, and is not likely feasible to accomplish on EFF's airgapped machine hosting its offline private signing key due to the lack of availability of NSS tools. To overcome this limitation, I will be porting one of either the Uhura tool that has been used in the past, or the pk1sign program[4] Yan had found referenced in a Bugzilla report. For now, that's what I'll be doing. I am feeling optimistic that, once this issue of generating an appropriate (i.e. verifiable by nsIDataSignatureVerifier) signature is resolved, writing tests for and refactoring the secure update mechanism I am building will be complete before long. I have compiled some of the discussion Yan and I have had via email into my weekly meeting notes[5], despite there having not been an actual meeting. As usual, I welcome any advice and input! Cheers, Zack [1]: https://github.com/redwire/https-everywhere/blob/feature/tests/https-everyw… [2]: https://github.com/redwire/https-everywhere/blob/rulesetUpdating/doc/update… [3]: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Inter… [4]: http://dxr.mozilla.org/mozilla-central/source/security/nss/cmd/pk1sign/pk1s… [5]: https://gist.github.com/redwire/b62f03905a826e79947a#week-8

3 2

[PATCH] entrynodes.c: Improve readability (issue 9971)
by Martin Kepplinger 08 Jul '14

08 Jul '14

Maybe we can do away with issue 9971 and improve readability: https://trac.torproject.org/projects/tor/ticket/9971 As response to this mail, I'll append seperate patches for the 3 sub-issues mentioned. They apply (and are build-tested) seperately to the current tree, so a maintainer can quickly pick one of them up, if happy with it. There shouldn't be a conflict in *1* and *2* but I could append a patchset anyway. sub-issue *3* is *only* a call for advice and will be written on top of the other ones, after discussion. 1* rename entry_guard_t's made_contact to used_so_save_if_down I think that's readable. Is that about what arma had in mind? 2* rename for_discovery argument of add_an_entry_guard() to I like probationary more than provisional. Those 2 are suggested in issue 9971. I chose forced_probationary for now, because isn't it strictly a suboptimal situation in terms of desired 'grade of anonymity'. What do you think? 3* NEEDS REVIEW FIRST: regarding the int arguments of add_an_entry_guard(). I look at: node_t *chosen is a node to add. prepend is set if the guard should become first in the list? there are 2 users of add_an_entry_guard() that pass it a chosen node. One is a bridge (prepend) and the other one is a user-defined node (!prepend), so: Given the fact that the list is not supposed to be long and the two 'users' are somewhat similar, why not prepend the node if explicitly given?

1 4

[PATCH] remove test for remote SOCKS Port at config validation
by Martin Kepplinger 08 Jul '14

08 Jul '14

(why doesn't git send-email work for this list?) this is UNTESTED and for now, more of a question if this may suffice to close ticket 4019: -- Martin Kepplinger http://martinkepplinger.com

1 1

[ot] tor2web static maps
by grarpamp 07 Jul '14

07 Jul '14

I think I saw these posted here earlier from a tor2web person. The url's seem unreliable at times. Are there new, updated, or canonical links to this data? Or to a document outlining them? Thanks. https://antani.tor2web.org/antanistaticmap/stats/yesterday https://antani.onion.to/antanistaticmap/stats/yesterday

2 2

[PATCH] Add some words about meek in proposal 203
by Lunar 07 Jul '14

07 Jul '14

This is mostly David Fifield's words from an email exchange. --- I re-read proposal 203 the other day and wondered how it was related to the meek pluggable transport. As I might not be the only one, I thought it could be worthwhile to share David's answer. Feel free to improve! proposals/203-https-frontend.txt | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/proposals/203-https-frontend.txt b/proposals/203-https-frontend.txt index 26101b3..df30cd5 100644 --- a/proposals/203-https-frontend.txt +++ b/proposals/203-https-frontend.txt @@ -245,3 +245,31 @@ Side note: What to put on the webserver? "Something to add to your HTTPS website" rather than as a standalone installation. +Related work: + + meek [1] is a pluggable transport that uses HTTP for carrying bytes + and TLS for obfuscation. Traffic is relayed through a third-party + server (Google App Engine). It uses a trick to talk to the third + party so that it looks like it is talking to an unblocked server. + + meek itself is not really about HTTP at all. It uses HTTP only + because it's convenient and the big Internet services we use as cover + also use HTTP. meek uses HTTP as a transport, and TLS for + obfuscation, but the key idea is really "domain fronting," where it + appears to the censor you are talking to one domain (www.google.com) + but behind the scenes you are talking to another + (meek-reflect.appspot.com) The meek-server program is an ordinary + HTTP (not necessarily even HTTPS!) server, whose communication is + easily fingerprintable; but that doesn't matter because the censor + never sees that part of the communication, only the communication + between the client and CDN. + + One way to think about the difference: if a censor (somehow) learns + the IP address of a bridge as described in this proposal, it's easy + and low-cost for the censor to block that bridge by IP address. meek + aims to make it much more expensive: even if you know a domain is + being used (in part) for circumvention, in order to block it have to + block something important like the Google frontend or CloudFlare + (high collateral damage). + +1. https://trac.torproject.org/projects/tor/wiki/doc/meek -- 1.7.10.4

3 3

Spinning off Directory Archive from Metrics Portal
by Karsten Loesing 07 Jul '14

07 Jul '14

Hello devs, I'm continuously tweaking the Metrics Portal [0] in the attempt to make it more useful. My latest idea is to finally spin off the Directory Archive part from it, which is the part that serves descriptor tarballs. I'd like to hear what people think about that. Let me give you some more context. The Metrics Portal serves three main purposes: 1. Graphs [1]: there are graphs on network size, network diversity, user number estimates, and performance measurements. This is probably what most visitors are interested in. In addition to graphs, there are also tables and .csv files for download. 2. Research [2]: we offer descriptor tarballs for download and explain the data formats. This is mostly interesting for researchers and developers. (This is the part that I'd like to spin off and move to a separate place.) 3. Status [3]: we provided (and still provide) services that are based on archived descriptors. This includes ExoneraTor and Consensus Health, both of which have moved to their own sites, and it includes Relay Search which is high on the list of endangered services. While we (did) provide these services on the Metrics Portal, they're almost gone. So, my plan is to move away the Research part, number 2 above, and re-organize the remaining Graphs part to address visitors who are not necessarily researchers or developers. The new Directory Archive website would contain the following content: - Start page: possibly re-using parts from the current start page [0]. - Data: How to obtain the data, possibly re-using parts from the current Data page [4], but without separate pages for file lists. - Formats: similar to the current Data Formats page [5]. - Tools: similar to the current Tools page [6]. What would be a good name for the new website holding the Tor Directory Archive? How about: - CollecTor, collector.torproject.org (not available yet) or - AggregaTor, aggregator.torproject.org (not available yet) On the software side, I'd like to remove all dynamic (Java) parts from the new website and have it served by Apache alone instead of Tomcat. The only parts that still need to be dynamically generated would be file lists, and I'd like to solve that by using Apache directory listings or some other Apache module. The re-organized Metrics Portal is going to have the following content: - Start page: possibly re-using parts from the current start page [0]. - Graphs: all four sub pages from the current Graphs page [1], so Network, Bubbles, Users, and Performance. - Aggregated data: the processed data behind graphs that is currently available on the Statistics page [7]. Speaking of, if anybody wants to help design the new website (or help re-design the existing Metrics Portal website once the cruft is gone), your help would be much appreciated. Bonus points if no JavaScript is required, at least for the Directory Archive website. Please contact me if you're interested. Any feedback welcome! Thanks! All the best, Karsten [0] https://metrics.torproject.org/ [1] https://metrics.torproject.org/graphs.html [2] https://metrics.torproject.org/research.html [3] https://metrics.torproject.org/status.html [4] https://metrics.torproject.org/data.html [5] https://metrics.torproject.org/formats.html [6] https://metrics.torproject.org/tools.html [7] https://metrics.torproject.org/stats.html

3 6

7 Dir Servers Dropping - Doctor Error?
by Tom Ritter 07 Jul '14

07 Jul '14

On 6 July 2014 18:59, doctor role account <doctor(a)cappadocicum.torproject.org> wrote: > ERROR: Unable to retrieve the consensus from maatuska (http://171.25.193.9:443/tor/status-vote/current/consensus) timed out > ERROR: Unable to retrieve the consensus from tor26 (http://86.59.21.38:80/tor/status-vote/current/consensus) timed out > ERROR: Unable to retrieve the consensus from urras (http://208.83.223.34:443/tor/status-vote/current/consensus) timed out > ERROR: Unable to retrieve the consensus from gabelmoo (http://212.112.245.170:80/tor/status-vote/current/consensus) timed out > ERROR: Unable to retrieve the consensus from moria1 (http://128.31.0.39:9131/tor/status-vote/current/consensus) timed out > ERROR: Unable to retrieve the consensus from dannenberg (http://193.23.244.244:80/tor/status-vote/current/consensus) timed out > ERROR: Unable to retrieve the consensus from Faravahar (http://154.35.32.5:80/tor/status-vote/current/consensus) timed out I've been keeping an eye on consensus health, it seems to be pretty reliable, but this is an obvious outlier. I assume it was a doctor error of some sort? -tom

2 1