Re: [tor-talk] AORTA - others tried it?
On my Debian system, programs like Firefox and Chromium do not work > > with TorSocks. For AORTA I haven't been able to find a program that > > does not work under AORTA. Please let me know if you have a program > > that does not work with AORTA. > > Well, I'm not sure what is cause this: > > $ aorta -c -t telnet abcd1234abcd1234.onion 80 > > WARNING NOT testing if Tor handles all Internet traffic. > > RUNNING telnet abcd1234abcd1234.onion 80 > Trying 10.216.233.115... > telnet: connect to address 10.216.233.115: Connection timed out > Trying fa93:ac5e:c801:b104:ad21:2e27:0f18:b4f... > telnet: connect to address fa93:ac5e:c801:b104:ad21:2e27:0f18:b4f: > Invalid argument > > AORTA CLOSED ... > > OTOH this works fine: > > $ torsocks telnet abcd1234abcd1234.onion 80 > Trying 127.39.20.0... > Connected to abcd1234abcd1234.onion. > Escape character is '^]'. > > Why is AORTA failing, also why is result of trying to connect on > IPV6 > "Invalid argument"? This is strange in multiple ways: First the address. abcd1234abcd1234.onion cannot be a *real* onion address because onion addresses are supposed to be unreadable :-) I suspected it to be some kind of test address so i tried to find it in the Tor source code. No luck. But I got a telnet reply when i tried to connect to it with AORTA. The connection was closed immediate after i got the "Escape character is" message. With torsocks the address was not resolved and no connection was established. About the IPV6 address in your AORTA session. I do not know how you got this address. AORTA should only resolve to an IPV4 address in the 10.192.0.0/10 range. Regards, Rob. https://hoevenstein.nl -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Tor 0.3.3.2-alpha is released
Hi, all! There's a new alpha Tor release! Because it's an alpha, you should only run it if you're ready to find more bugs than usual, and report them on trac.torproject.org. The source code is available from the usual place on www.torproject.org; if you build Tor from source, why not give it a try? And if you don't build Tor from source, packages should be ready over the coming days, with a Tor Browser alpha release likely in a couple of weeks. = Here's what's new! Changes in version 0.3.3.2-alpha - 2018-02-10 Tor 0.3.3.2-alpha is the second alpha in the 0.3.3.x series. It introduces a mechanism to handle the high loads that many relay operators have been reporting recently. It also fixes several bugs in older releases. If this new code proves reliable, we plan to backport it to older supported release series. o Major features (denial-of-service mitigation): - Give relays some defenses against the recent network overload. We start with three defenses (default parameters in parentheses). First: if a single client address makes too many concurrent connections (>100), hang up on further connections. Second: if a single client address makes circuits too quickly (more than 3 per second, with an allowed burst of 90) while also having too many connections open (3), refuse new create cells for the next while (1-2 hours). Third: if a client asks to establish a rendezvous point to you directly, ignore the request. These defenses can be manually controlled by new torrc options, but relays will also take guidance from consensus parameters, so there's no need to configure anything manually. Implements ticket 24902. o Major bugfixes (netflow padding): - Stop adding unneeded channel padding right after we finish flushing to a connection that has been trying to flush for many seconds. Instead, treat all partial or complete flushes as activity on the channel, which will defer the time until we need to add padding. This fix should resolve confusing and scary log messages like "Channel padding timeout scheduled 221453ms in the past." Fixes bug 22212; bugfix on 0.3.1.1-alpha. o Major bugfixes (protocol versions): - Add Link protocol version 5 to the supported protocols list. Fixes bug 25070; bugfix on 0.3.1.1-alpha. o Major bugfixes (scheduler, consensus): - The scheduler subsystem was failing to promptly notice changes in consensus parameters, making it harder to switch schedulers network-wide. Fixes bug 24975; bugfix on 0.3.2.1-alpha. o Minor features (denial-of-service avoidance): - Make our OOM handler aware of the geoip client history cache so it doesn't fill up the memory. This check is important for IPv6 and our DoS mitigation subsystem. Closes ticket 25122. o Minor features (directory authority): - When directory authorities are unable to add signatures to a pending consensus, log the reason why. Closes ticket 24849. o Minor features (geoip): - Update geoip and geoip6 to the February 7 2018 Maxmind GeoLite2 Country database. o Minor features (logging, diagnostic): - When logging a failure to create an onion service's descriptor, also log what the problem with the descriptor was. Diagnostic for ticket 24972. o Minor bugfix (channel connection): - Use the actual observed address of an incoming relay connection, not the canonical address of the relay from its descriptor, when making decisions about how to handle the incoming connection. Fixes bug 24952; bugfix on 0.2.4.11-alpha. Patch by "ffmancera". o Minor bugfix (directory authority): - Directory authorities, when refusing a descriptor from a rejected relay, now explicitly tell the relay (in its logs) to set a valid ContactInfo address and contact the bad-relays@ mailing list. Fixes bug 25170; bugfix on 0.2.9.1. o Minor bugfixes (all versions of Tor): - Use the "misspell" tool to detect and fix typos throughout the source code. Fixes bug 23650; bugfix on various versions of Tor. Patch from Deepesh Pathak. o Minor bugfixes (circuit, cannibalization): - Don't cannibalize preemptively-built circuits if we no longer recognize their first hop. This situation can happen if our Guard relay went off the consensus after the circuit was created. Fixes bug 24469; bugfix on 0.0.6. o Minor bugfixes (correctness): - Remove a nonworking, unnecessary check to see whether a circuit hop's identity digest was set when the circuit failed. Fixes bug 24927; bugfix on 0.2.4.4-alpha. o Minor bugfixes (logging): - Don't treat inability to store a cached consensus object as a bug: it can happen normally when we are out of disk space. Fixes bug 24859; bugfix on 0.3.1.1-alpha. - Fix a (mostly harmless) race condition when invoking
Re: [tor-talk] Tor 0.3.3.2-alpha is released
thank you for this important release! Nick Mathewson: > o Major features (denial-of-service mitigation): > - Give relays some defenses against the recent network overload. We > start with three defenses (default parameters in parentheses). > First: if a single client address makes too many concurrent > connections (>100), hang up on further connections. Second: if a > single client address makes circuits too quickly (more than 3 per > second, with an allowed burst of 90) while also having too many > connections open (3), refuse new create cells for the next while > (1-2 hours). Third: if a client asks to establish a rendezvous > point to you directly, ignore the request. These defenses can be > manually controlled by new torrc options, but relays will also > take guidance from consensus parameters, so there's no need to > configure anything manually. Implements ticket 24902. Do you advise relay operators against using OutboundBindAddress and OutboundBindAddressExit due to the "is this a relay IP?" check not being able to handle such relays because their outbound IP does not match their OR IP? https://trac.torproject.org/projects/tor/ticket/25193 > It is possible to do "tor-in-tor" meaning a tor client connection can exit > the network and come back at a Guard node. > > And if this happens to be detected by the DoS subsystem, we'll blacklist > the Exit relay for a while. That is *NOT* good. thank you -- https://mastodon.social/@nusenu twitter: @nusenu_ signature.asc Description: OpenPGP digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] AORTA - others tried it?
> On 10 Feb 2018, at 10:15, Rob van der Hoeven wrote: > > On my Debian system, programs like Firefox and Chromium do not work >> >> Well, I'm not sure what is cause this: >> >> $ aorta -c -t telnet abcd1234abcd1234.onion 80 > First the address. abcd1234abcd1234.onion cannot be a *real* onion > address because onion addresses are supposed to be unreadable :-) This cannot be a real onion address because it contains the character "1" which is impossible for real onions. "1" is specifically not a character used by Base32 encoding used by onion addresses. https://en.wikipedia.org/wiki/Base32#RFC_4648_Base32_alphabet Since the domain name is obviously incorrect for the .onion TLD it's questionable if a tool should even try to connect to it. Likewise you'd refuse any .onion domain that isn't of exactly 16 (v2 onion) or 54 characters (v3 onion) in length. Maybe some systems that usually resolve hostnames through tor, fall back to a local or another resolver when they receive an NX as a fallback. Best regards MacLemon signature.asc Description: Message signed with OpenPGP -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] torified nodejs: server crashes
Dear developers, I am trying to develop a simple networking application based on node.js 'net' library. Server supposed to run in torified environment. My setup is linux Ubuntu 16.04. intalled tor and torsocks. Torsocks allows inbound connection and outbound on localhost. nodejs app is basically a minimal tcp server based on 'net' library. I run it like this: torsocks nodejs app.js, while tor process is also runnning The server starts, but when client connects - it crashes with seg fault. When I run the same node.js server in regular shell without torsocks, but when tor is running - it works fine So far I tried plain C and python servers - they both worked in torified shell, but node.js failing. Is there a way to make nodejs working under torsocks? What could be the problem? Thanks you very much! -- Warm regards, Konstantin Rybakov -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] AORTA - others tried it?
On my Debian system, programs like Firefox and Chromium do not work > with TorSocks. For AORTA I haven't been able to find a program that > does not work under AORTA. Please let me know if you have a program > that does not work with AORTA. Well, I'm not sure what is cause this: $ aorta -c -t telnet abcd1234abcd1234.onion 80 WARNING NOT testing if Tor handles all Internet traffic. RUNNING telnet abcd1234abcd1234.onion 80 Trying 10.216.233.115... telnet: connect to address 10.216.233.115: Connection timed out Trying fa93:ac5e:c801:b104:ad21:2e27:0f18:b4f... telnet: connect to address fa93:ac5e:c801:b104:ad21:2e27:0f18:b4f: Invalid argument AORTA CLOSED ... OTOH this works fine: $ torsocks telnet abcd1234abcd1234.onion 80 Trying 127.39.20.0... Connected to abcd1234abcd1234.onion. Escape character is '^]'. Why is AORTA failing, also why is result of trying to connect on IPV6 "Invalid argument"? This is strange in multiple ways: First the address. abcd1234abcd1234.onion cannot be a *real* onion No, sorry, it's changed from the real address. The point was to observe aorta timing out a connection while torsocks connecting ok. I found unpredictable. But happening enough to create doubt in what aorta is doing. I got a telnet reply when i tried to connect to it with AORTA. The connection was closed immediate after i got the "Escape character is" message. With torsocks the address was not resolved and no connection was established. Well, you have discrepancies also. Why is the behavior different? Aren't both connections going through same tor? About the IPV6 address in your AORTA session. I do not know how you got this address. Doesn't telnet look for IPV6 if IPV4 fails? Where it got lookup, I can't say. What does aorta do when IPV6 is requested? AORTA should only resolve to an IPV4 address in the 10.192.0.0/10 range. - ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
