[tor-relays] Scramblesuit
Hi. I am trying to enable Scramblesuit for my bridge. I am wondering if there is a method to verify that it is working, similar to how obfs3 shows "registered server transport". There is not much out there about scramblesuit but there is one mention that the log should show " registered server transport scramble suit". Tor version is 0.2.5.8-rc Obfsproxy version 0.2.12 ExtORPort auto ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed Oct 01 03:03:28.000 [notice] Registered server transport 'obfs3' at ' 0.0.0.0:39491' Is there something wrong with my config? Thank you. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Loki1 and Loki2 closed
Hey fellow ops, Just an FYI today that Icetor lost two of it's fastest two exits that were hosted with Greenqloud here in Iceland, obviously would not recommend them as an ISP in the future regarding exit hosting. About two weeks ago we got notification that abuse notices were breaking their EULA and would be the reason for the termination. Today they shut down the nodes about 5 hours earlier than indicated, no ability to do data migration or save keys. Needless to say I'm not very happy with the entire situation and how it was handled. We'll soldier on with our remaining two exits and ifanyone is thinking of spinning up an exit in the future Icetor is still able to handle abuse contact for the relay. -Jason ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bandwidth not being used by Tor on Gigabit dedicated server
I've often found my servers accidentally bottlenecked by the default open file limit on some Linuxes. For example, on CentOS 6 this is 4096, which for an exit node tends to mean ~50Mbit/s per process. A single process will not saturate 1Gbit/s. Judging by the hardware (AES-NI support) you will need 3 or 4 instances running simultaneously to max the link. Tom s7r schreef op 30/09/14 20:31: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It has nothing to do with the location (US). There are fewer US exit relays than other countries in Europe. Check the CPU usage too, usually CPU is the bottleneck on high port speed servers. Tor does not know yet how to do multithreading. Do you have AES-NI hardware acceleration at your CPU? This is very helpful too. Install htop (yum -y install htop) and it will tell you exactly how much each core is used. Let us know. I see that you confirm CPU load is not the fault, but probably you are checking it via a tool which is reporting the usage for ALL CPU (all cores) - try with htop and see if there is just one core @ 98% usage and others at less than 10%. If the CPU is not the bottleneck, there is something at your provider (probably throttling Tor traffic to balance the other non-tor users in the same datacenter). If you built the network infrastructure there and know for sure such thing is not implemented there, don't really know what to say. CPU / RAM and Network interface is all you can test to see if it is the bottleneck for Tor. If all these are off the list, there is something upstream you. I repeat, the location is not the fault here, and I encourage adding more exits in the US. On 9/30/2014 8:52 PM, Jon Daniels wrote: Hi, My Tor node is not utilizing the bandwidth available to it. I have tried setting RelayBandwidthRate to various values with no change whatsoever in bandwidth usage. Running for 5 months with 99.77% uptime: https://globe.torproject.org/#/relay/1F6598EA09A82E7A5D3131E71A97C806E6FDA4A1 My node has used a maximum of about 4MB/s or about 40Mbps. I've been expecting it to use 10MB/sec to 30 MB/sec. It dropped from 4MB/sec to around 1MB/sec now. OS: CentOS 6.x 64bit latest CPU: Xeon E3 1230 MB: Supermicro X9SCL RAM: 8GB Network connection: 1000Mbps Bandwidth tests show the server can easily send or receive hundreds of Mbps. I have tweaked server settings trying to get the speed up to no avail. Tor v0.2.4.24 (git-549ec02c188842f6) running on Linux with Libevent 1.4.13-stable and OpenSSL 1.0.1e-fips. Relevant config: DirPort 9030 # what port to advertise for directory connections RelayBandwidthRate 30 MB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 30 MB # But allow bursts up to 200KB/s (1600Kbps) DisableDebuggerAttachment 0 ORPort 443 ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-995 # FTP over SSL, Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8087-8088 # Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept *:8332-8333 # BitCoin ExitPolicy accept *:8443
Re: [tor-relays] Bandwidth not being used by Tor on Gigabit dedicated server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > If the CPU is not the bottleneck, there is something at your provider > (probably throttling Tor traffic to balance the other non-tor users in > the same datacenter). If you built the network infrastructure there > and know for sure such thing is not implemented there, don't really > know what to say. CPU / RAM and Network interface is all you can test > to see if it is the bottleneck for Tor. If all these are off the list, > there is something upstream you. I recall reading on the Tor blog that there is a bit of a lull after you get the Guard flag for your relay. Given that these days Tor clients only choose one guard, is it possible that his relay just hasn't built up a list of Tor clients using it as a guard yet? Thank you, Derric Atzrott -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) iD8DBQFUKvs9hiwmHXffHDoRAkDYAKDSbBKYhzmzlMT3cobveMtkQKOQvQCgxt01 0gYSB0GikeUx92CaN3jJdSA= =E4B2 -END PGP SIGNATURE- public_key.gpg Description: Binary data ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bandwidth not being used by Tor on Gigabit dedicated server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It has nothing to do with the location (US). There are fewer US exit relays than other countries in Europe. Check the CPU usage too, usually CPU is the bottleneck on high port speed servers. Tor does not know yet how to do multithreading. Do you have AES-NI hardware acceleration at your CPU? This is very helpful too. Install htop (yum -y install htop) and it will tell you exactly how much each core is used. Let us know. I see that you confirm CPU load is not the fault, but probably you are checking it via a tool which is reporting the usage for ALL CPU (all cores) - try with htop and see if there is just one core @ 98% usage and others at less than 10%. If the CPU is not the bottleneck, there is something at your provider (probably throttling Tor traffic to balance the other non-tor users in the same datacenter). If you built the network infrastructure there and know for sure such thing is not implemented there, don't really know what to say. CPU / RAM and Network interface is all you can test to see if it is the bottleneck for Tor. If all these are off the list, there is something upstream you. I repeat, the location is not the fault here, and I encourage adding more exits in the US. On 9/30/2014 8:52 PM, Jon Daniels wrote: > Hi, > > My Tor node is not utilizing the bandwidth available to it. I have > tried setting RelayBandwidthRate to various values with no change > whatsoever in bandwidth usage. > > Running for 5 months with 99.77% uptime: > https://globe.torproject.org/#/relay/1F6598EA09A82E7A5D3131E71A97C806E6FDA4A1 > > My node has used a maximum of about 4MB/s or about 40Mbps. I've > been expecting it to use 10MB/sec to 30 MB/sec. It dropped from > 4MB/sec to around 1MB/sec now. > > OS: CentOS 6.x 64bit latest CPU: Xeon E3 1230 MB: Supermicro X9SCL > RAM: 8GB Network connection: 1000Mbps > > Bandwidth tests show the server can easily send or receive hundreds > of Mbps. I have tweaked server settings trying to get the speed up > to no avail. > > > Tor v0.2.4.24 (git-549ec02c188842f6) running on Linux with > Libevent 1.4.13-stable and OpenSSL 1.0.1e-fips. > > Relevant config: > > DirPort 9030 # what port to advertise for directory connections > > RelayBandwidthRate 30 MB # Throttle traffic to 100KB/s (800Kbps) > RelayBandwidthBurst 30 MB # But allow bursts up to 200KB/s > (1600Kbps) > > DisableDebuggerAttachment 0 > > ORPort 443 > > ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 > # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # > finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept > *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 > # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # > LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # > kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept > *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy > accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over > SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # > kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept > *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS > management for firewall ExitPolicy accept *:989-995 # FTP over SSL, > Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 > over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept > *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec > ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept > *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy > accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy > accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility > Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) > ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept > *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy > accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy > accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy > accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC > ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # > XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market > ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC > ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC > SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # > HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy > accept *:8080 # HTTP Proxies ExitPolicy accept *:8087-8088 # > Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept > *:8332-8333 # BitCoin ExitPolicy accept *:8443 # PCsync HTTPS > ExitPolicy accept *: # HTTP Proxies, NewsEDGE ExitPolicy accept > *:9418 # git ExitPolicy accept *: # distinct ExitPolicy accept > *:1 # Network Data Management Protocol ExitPolicy accept > *:11371 # OpenPGP hkp (http keyserver
[tor-relays] Bandwidth not being used by Tor on Gigabit dedicated server
Hi, My Tor node is not utilizing the bandwidth available to it. I have tried setting RelayBandwidthRate to various values with no change whatsoever in bandwidth usage. Running for 5 months with 99.77% uptime: https://globe.torproject.org/#/relay/1F6598EA09A82E7A5D3131E71A97C806E6FDA4A1 My node has used a maximum of about 4MB/s or about 40Mbps. I've been expecting it to use 10MB/sec to 30 MB/sec. It dropped from 4MB/sec to around 1MB/sec now. OS: CentOS 6.x 64bit latest CPU: Xeon E3 1230 MB: Supermicro X9SCL RAM: 8GB Network connection: 1000Mbps Bandwidth tests show the server can easily send or receive hundreds of Mbps. I have tweaked server settings trying to get the speed up to no avail. Tor v0.2.4.24 (git-549ec02c188842f6) running on Linux with Libevent 1.4.13-stable and OpenSSL 1.0.1e-fips. Relevant config: DirPort 9030 # what port to advertise for directory connections RelayBandwidthRate 30 MB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 30 MB # But allow bursts up to 200KB/s (1600Kbps) DisableDebuggerAttachment 0 ORPort 443 ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-995 # FTP over SSL, Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8087-8088 # Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept *:8332-8333 # BitCoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *: # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *: # distinct ExitPolicy accept *:1 # Network Data Management Protocol ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:12350 # Skype ExitPolicy accept *:19294 # Google Voice TCP ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept *:23456 # Skype ExitPolicy accept *:33033 # Skype ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* In addition, there's another Tor node running at the same ISP (but by a different person), on completely different hardware and a different router, that exhibits the same issue: https://globe.torproject.org/#/relay/50F37822AFA257B24B3343D9BBFB0442E900FB4C For background, I built and manage the network both servers are hosted on and have been doing so for 20 years. I also built both servers. The network is at less than 15% capacity, 99% of the time. CPU load is always at 0.00. Based in the USA, west coast. Ideas? Is there simply less demand for tor traffic in the US? Cheers, Jon ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Oniontip
Mike Perry transcribed 6.0K bytes: > Thomas White: > > Hmmm... appears to be have been upgraded since I last checked then > > (which was only a few weeks ago!). Nicely done oniontip. I stand > > corrected. > > Well, my original ask was for everyone to be able to verify that all > 12.36 BTC that oniontip has received (as of right now) has actually been > distributed how the users have asked. Mike Perry and I took a look at the Oniontip codebase this afternoon. The primary concern was with respect to the `ONIONTIP_BITCOIN_PUBLIC_SEED` in your payment verification script, [0] which is passed to the `bitcoin.electrum_address()` function. [1] The `bitcoin.electrum_address()` function is meant to take what they call a "masterkey". [2] (Check out that `crack_electrum_wallet()` function right beneath it!) It appears as if `electrum_address()` is merely a thin wrapper around `electrum_pubkey()` [3] which generates a new private key with the incremented counter, concatenating it with the "masterkey", taking the sha256 of that, and then generating the key by doing a (really crappily implemented, IMO) elliptic curve scalar multiplication of the (public, in the `bitcoin` module source code [4]) group generator times the private key, then shoving it into `privkey_to_pubkey()` to get the address. [5] Because all of these one-way functions are computable if one knows the original "masterkey" plus the incremented counter, this means that anyone who knows the `ONIONTIP_BITCOIN_PUBLIC_SEED` can generate all your private keys. If you plan to keep using that Electrum API, you should regenerate that `ONIONTIP_BITCOIN_PUBLIC_SEED` and keep it secret. [0]: https://github.com/DonnchaC/oniontip/blob/master/scripts/payment-check.py#L12 [1]: https://github.com/DonnchaC/oniontip/blob/master/scripts/payment-check.py#L30 [2]: https://github.com/vbuterin/pybitcointools/blob/fa9856fede9e601c4b9f5ed75f11f899c02a51a3/bitcoin/deterministic.py#L48 [3]: https://github.com/vbuterin/pybitcointools/blob/fa9856fede9e601c4b9f5ed75f11f899c02a51a3/bitcoin/deterministic.py#L34 [4]: https://github.com/vbuterin/pybitcointools/blob/master/bitcoin/main.py#L20 [5]: https://github.com/vbuterin/pybitcointools/blob/master/bitcoin/main.py#L342 -- ♥Ⓐ isis agora lovecruft _ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt signature.asc Description: Digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
