- tor-relays - lists.torproject.org

obfs3 a risk to scramblesuit?
by Delton Barnes 14 Feb '14

14 Feb '14

I am running a bridge with both obfs3 and scramblesuit. obfs3 is vulnerable to active probing. Say someone in China makes the mistake of connecting with obfs3 instead of scramblesuit, and active probing identifies it as a Tor bridge. Wouldn't the bridge IP address then be blacklisted, making it impossible for other people to connect even with scramblesuit? Would it make sense, then, as a bridge operator to elect to only support scramblesuit, even though no one will use it for a while? It seems you are only as good as your weakest transport. Thanks, Delton p.s. Would reply to original thread about scramblesuit, but I only just joined the mailing list, and cannot figure out how to reply to preexisting messages.

2 1

Re: [tor-relays] New obfsproxy transport: scramblesuit [bridge operators: please upgrade!]
by Matt 14 Feb '14

14 Feb '14

On Thu, 13 Feb 2014 18:10:38 +0000 George Kadianakis <desnacked(a)riseup.net> wrote: > > Hm, the "Could not set up listener" error message usually appears when > something is already listening on the port that obfsproxy wants to > bind to (Twisted throws the error.CannotListenError exception). > I managed to avoid the problem by running `killall obfsproxy` before restarting Tor. This time around I registered server transport 'obfs3' and registered server transport 'scramblesuit'. Thanks!

1 0

Re: [tor-relays] New obfsproxy transport: scramblesuit [bridge operators: please upgrade!]
by Matt 13 Feb '14

13 Feb '14

On Wed, 12 Feb 2014 18:29:26 +0000 Matt <matt(a)pagan.io> wrote: > I installed obfsproxy through pip. Running Tor 0.2.5.1, I'm seeing > this message: > > [warn] Managed proxy at '/usr/local/bin/obfsproxy' failed the > configuration protocol and will be destroyed. > > That doesn't sound too great. What does this message mean? > Here is more from the debug log: Feb 12 16:38:27.000 [debug] onion_extend_cpath(): Path is complete: 3 steps long Feb 12 16:38:27.000 [debug] circuit_handle_first_hop(): Looking for firsthop '[redacted IPv4]:443' Feb 12 16:38:27.000 [debug] circuit_handle_first_hop(): Conn open. Delivering first onion skin. Feb 12 16:38:27.000 [debug] circuit_send_next_onion_skin(): First skin; sending create cell. Feb 12 16:38:27.000 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() found nothing for circ_id 2147489864, channel ID 2 (0x2ba73fe349b0) Feb 12 16:38:27.000 [debug] circuit_deliver_create_cell(): Chosen circID 2147489864. Feb 12 16:38:27.000 [debug] circuitmux_attach_circuit(): Attaching circuit 2147489864 on channel 2 to cmux 0x2ba73f9a1c90 Feb 12 16:38:27.000 [debug] circuitmux_attach_circuit(): Attaching circuit 2147489864 on channel 2 to cmux 0x2ba73f9a1c90 Feb 12 16:38:27.000 [debug] append_cell_to_circuit_queue(): Made a circuit active. Feb 12 16:38:27.000 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to '$5A0EF08FC99F236C5E48FB52E649F092088D009C=ganooloonix at [redacted IPv4]' Feb 12 16:38:27.000 [debug] pt_configure_remaining_proxies(): Configuring remaining managed proxies (1)! Feb 12 16:38:27.000 [info] handle_proxy_line(): Got a line from managed proxy '/usr/local/bin/obfsproxy': (VERSION 1) Feb 12 16:38:27.000 [info] handle_proxy_line(): Got a line from managed proxy '/usr/local/bin/obfsproxy': (SMETHOD-ERROR obfs3 Could not set up listener.) Feb 12 16:38:27.000 [warn] Server managed proxy encountered a method error. (obfs3 Could not set up listener.) Feb 12 16:38:27.000 [warn] Managed proxy at '/usr/local/bin/obfsproxy' failed the configuration protocol and will be destroyed. Feb 12 16:38:27.000 [info] tor_process_handle_destroy(): Terminated process with PID '30355'. Feb 12 16:38:27.000 [info] mark_my_descriptor_dirty(): Decided to publish new relay descriptor: configured managed proxies Feb 12 16:38:27.000 [debug] conn_write_callback(): socket 17 wants to write. Feb 12 16:38:27.000 [debug] flush_chunk_tls(): flushed 1542 bytes, 0 ready to flush, 0 remain. Feb 12 16:38:27.000 [debug] connection_handle_write_impl(): After TLS write of 1542: 0 read, 1589 written Feb 12 16:38:27.000 [debug] channel_write_packed_cell(): Writing packed_cell_t 0x2ba7403cb698 to channel 0x2ba73fe349b0 with global ID 2 Feb 12 16:38:27.000 [debug] channel_flush_from_first_active_circuit(): Made a circuit inactive.

2 1

Re: [tor-relays] New obfsproxy transport: scramblesuit [bridge operators: please upgrade!]
by Matt 12 Feb '14

12 Feb '14

On Mon, 10 Feb 2014 16:04:56 +0000 George Kadianakis <desnacked(a)riseup.net> wrote: > Greetings, > > a few days ago we integrated ScrambleSuit to obfsproxy. ScrambleSuit > is a pluggable transport by Philipp Winter; you can find more about it > at: http://www.cs.kau.se/philwint/scramblesuit/ > > If you are running a bridge, please consider upgrading your obfsproxy > to the latest version (0.2.6) by using pip or fetching the latest git > master. Unfortunately, we don't have Linux packages yet, but we will > hopefully have some soon. In the meanwhile, we would appreciate some > testing :) > > After you upgrade obfsproxy, please change your ServerTransportPlugin > line from: > ServerTransportPlugin obfs2,obfs3 exec /usr/bin/obfsproxy > managed to: > ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy > managed > > This will disable obfs2 [0] and enable scramblesuit. > > It's also important to know that scramblesuit is a password-based > pluggable transport, which means that each scramblesuit bridge has a > password and if the user doesn't know the password he/she can't > connect to the bridge. If you publishing your bridge to BridgeDB, Tor > will automatically send the ScrambleSuit password to BridgeDB so that > clients can get it. By default ScrambleSuit will generate a random > password; if you want to specify your own password, you can use a > torrc line like this: > ServerTransportOptions scramblesuit > password=LLDNOWV7I4P6RKFJMDEMIY2GNU2IQISA > > By the way, expect not to see any scramblesuit users in the > beginning. After a few people have set up scramblesuit bridges, we > will roll out a Tor Browser Bundle with scramblesuit enabled. > > Feel free to ask any questions you have! > > Thanks! > > PS: If you are running a bridge without any pluggable transports, > please consider installing obfsproxy [1]. Normal bridges are not > hard to block these days and we are working on increasing the > number of obfuscated bridges out there. > > [0]: https://trac.torproject.org/projects/tor/ticket/10314 > [1]: https://www.torproject.org/projects/obfsproxy.html.en > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays I installed obfsproxy through pip. Running Tor 0.2.5.1, I'm seeing this message: [warn] Managed proxy at '/usr/local/bin/obfsproxy' failed the configuration protocol and will be destroyed. That doesn't sound too great. What does this message mean?

1 0

New obfsproxy transport: scramblesuit [bridge operators: please upgrade!]
by George Kadianakis 12 Feb '14

12 Feb '14

Greetings, a few days ago we integrated ScrambleSuit to obfsproxy. ScrambleSuit is a pluggable transport by Philipp Winter; you can find more about it at: http://www.cs.kau.se/philwint/scramblesuit/ If you are running a bridge, please consider upgrading your obfsproxy to the latest version (0.2.6) by using pip or fetching the latest git master. Unfortunately, we don't have Linux packages yet, but we will hopefully have some soon. In the meanwhile, we would appreciate some testing :) After you upgrade obfsproxy, please change your ServerTransportPlugin line from: ServerTransportPlugin obfs2,obfs3 exec /usr/bin/obfsproxy managed to: ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed This will disable obfs2 [0] and enable scramblesuit. It's also important to know that scramblesuit is a password-based pluggable transport, which means that each scramblesuit bridge has a password and if the user doesn't know the password he/she can't connect to the bridge. If you publishing your bridge to BridgeDB, Tor will automatically send the ScrambleSuit password to BridgeDB so that clients can get it. By default ScrambleSuit will generate a random password; if you want to specify your own password, you can use a torrc line like this: ServerTransportOptions scramblesuit password=LLDNOWV7I4P6RKFJMDEMIY2GNU2IQISA By the way, expect not to see any scramblesuit users in the beginning. After a few people have set up scramblesuit bridges, we will roll out a Tor Browser Bundle with scramblesuit enabled. Feel free to ask any questions you have! Thanks! PS: If you are running a bridge without any pluggable transports, please consider installing obfsproxy [1]. Normal bridges are not hard to block these days and we are working on increasing the number of obfuscated bridges out there. [0]: https://trac.torproject.org/projects/tor/ticket/10314 [1]: https://www.torproject.org/projects/obfsproxy.html.en

4 10

Trusted Tor Traceroute Scoreboard Link Modified
by Anupam Das 11 Feb '14

11 Feb '14

Hi Relay Operators, We have made some modifications to the way we are running our live scoreboard script. Previously we were running into some problems with handling multiple simultaneous web requests, as the server started a heavy script for each incoming request. Now we are updating a static HTML files every 10 minutes. The link of our scoreboard has changed. Now the scoreboard is available at- http://datarepo.cs.illinois.edu/relay_scoreboard.html Sorry for the inconveniences. Thanks Anupam

2 2

Re: [tor-relays] reading the captchas
by eliaz 11 Feb '14

11 Feb '14

On 2/10/2014 9:37:23 AM, Lunar (lunar(a)torproject.org) wrote: > eliaz: > > Would it be possible for someone to change the captcha images at the > URL > > for getting bridges, without of course lessening their effectiveness? > > The present ones are pretty much unreadable, to this human at least. - > eliaz > > The issue is already tracked, see: > https://trac.torproject.org/projects/tor/ticket/10809 > -- > Lunar <lunar(a)torproject.org> Thanks for the pointer & your work. I see it's more complicated than I thought. Hope it gets fixed soon, magnifying the screen isn't of much help. I'm reluctant to suggest the page to people as long as reading the captchas is so difficult. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

1 0

High speed exit
by Craig C-S 10 Feb '14

10 Feb '14

Hi all, I've been running a few fail relays over the past few years. All relays I run they begin with the prefix "Telos". I've recently come across a really good deal http://www.soyoustart.com/ca/en/ on hosting..., and begun hosting "TelosTor" and "TelosTor2" from 192.99.8.96. I would welcome any comments on security. At the moment I do not have a stable IP to access them, so have defaulted to 1/min IP access for OpenSSH. I would relish the TOR communities feedback in order to further secure my tor exit node. Thanks! Craig

8 10

Relay bandwidth
by Tora Tora Tora 09 Feb '14

09 Feb '14

I have configured Tor with the following (with daily accounting): RelayBandwidthRate 384 KB RelayBandwidthBurst 512 KB I always assumed that the burst bandwidth will set the maximum relay bandwidth. However, by using iftop, I can see individual connections with speeds as high as 2+ Mbps. Even when individual connections are not exceeding burst speeds, adding up bandwidth of all connections would probably exceed allowed relay burst bandwidth. Is this because Tor is using up the bandwidth allowance, since it is well below its long-time average or is this something unexpected that should not be happening?

4 5

using Arm to manage nodes
by jason＠icetor.is 08 Feb '14

08 Feb '14

Hello all, This is something that's bothered me for quite some time. I often use arm (https://www.torproject.org/projects/arm.html.en) for monitoring my relays and to keep a quick eye on things like overall bandwidth consumed, traffic stats and my favorite client locale statistics. I run it in a screen session and often when I re-attach the session often the keymapping is all messed up and the arrow keys will offer to close arm. Usually it will correct after I shift-m to get to the menu and switch around a few times. Has anyone else experienced this and how did you solve it? -Jason

6 8