I think that can be good choice compress packets, statistical sniffer
Hello, Compressed packets that outs of client to Tor server are not the same packets that arrive in the Web ser server decompressed, different number. The problem is that can overload Tor server. -- -- Publicidad http://www.pas-world.com
bandwidth limit strangeness
Hi, I'm running a tor server called 'Grepular'. At the moment it's a partial exit node in that it only exits a few specific ports. It's also a directory mirror. I'm running version 0.1.2.13, with this config: SocksPort 9050 SocksListenAddress 0.0.0.0 RunAsDaemon 1 DataDirectory /var/lib/tor ControlPort 9051 BandwidthRate 64KB BandwidthBurst 64KB MaxAdvertisedBandwidth 64KB Nickname grepular Address tor-node.grepular.com ORPort 443 ORListenAddress 85.234.136.20:9001 DirPort 80 DirListenAddress 85.234.136.20:9030 ExitPolicy accept *:20-23,accept *:53,accept *:109-115,accept *:123,accept *:143,accept *:389,accept *:465,accept *:587,accept *:636,accept *:989-995,accept *:1080,accept *:6660-6667,reject *:* I use the following iptables rules to redirect port 80 and 443 connections to the actual ports tor is listening on: iptables -t nat -A PREROUTING -d 85.234.136.20 -p tcp --dport 80 -j DNAT --to-destination 85.234.136.20:9030 iptables -t nat -A PREROUTING -d 85.234.136.20 -p tcp --dport 443 -j DNAT --to-destination 85.234.136.20:9001 With the bandwidth limits set as they are, why is tor using up nearly 1 Megabit per second? I thought it might be the directory mirror not being counted in the bandwidth usage, but from googling, I see this shouldn't be the case? I have much more spare capacity than 64KB/sec but I'm loathed to increase the current limits in my config until I'm confident I can accurately control the usage. Mike
Accept-encoding: gzip
As a directory mirror, current requests for the mirror data cause about 2.7MB of data transfer. If the data could be delivered compressed with gzip that could significantly reduce the transfered data... The main benefit of this being more bandwidth available for routing instead of directory transfers. This could be done in a backwards compatible fashion simply by using the http Accept-encoding: gzip option. This could even be an option that you enable/disable from the torrc. Am I right? Or am I missing something? Mike
Behaviour of Address on a multi-ip server
Hi, My server has many IP addresses. I was paranoid that even though I set Address in my configuration, outgoing connections might originate from one of the other IP 's on the server. So to combat this I use the following iptables rule: iptables -t nat -A POSTROUTING -s ! 85.234.136.20 -m owner --uid-owner debian-tor -j SNAT --to-source 85.234.136.20 Where 'debian-tor' is the user my tor process runs as, and 85.234.136.20 is the IP I want all tor outgoing connections to appear from. My question is. Is this a waste of time? Does tor already originate connections from the same IP it listens on? If not, it should... At the very minimum, it should be a documented issue. Thanks, Mike
Re: Behaviour of Address on a multi-ip server
On Thu, Apr 26, 2007 at 12:02:41PM +0100, [EMAIL PROTECTED] wrote 0.7K bytes in 19 lines about: : Where 'debian-tor' is the user my tor process runs as, and : 85.234.136.20 is the IP I want all tor outgoing connections to appear : from. : : My question is. Is this a waste of time? Does tor already originate : connections from the same IP it listens on? If not, it should... At : the very minimum, it should be a documented issue. It's documented in the man page as OutboundBindAddress. It may also be on the wiki somewhere too. -- Andrew
Re: Behaviour of Address on a multi-ip server
* on the Thu, Apr 26, 2007 at 09:49:39AM -0400, [EMAIL PROTECTED] wrote: : Where 'debian-tor' is the user my tor process runs as, and : 85.234.136.20 is the IP I want all tor outgoing connections to appear : from. : : My question is. Is this a waste of time? Does tor already originate : connections from the same IP it listens on? If not, it should... At : the very minimum, it should be a documented issue. It's documented in the man page as OutboundBindAddress. It may also be on the wiki somewhere too. So it is. I'm not sure how I missed that. Thanks. Mike
ip-port.torhosts.nighteffect.us and exim
I've been looking into how to use this with Exim4. I just thought I'd
share it here for the benefit of the archives.
warn dnslists=
$interface_port.${sg{$interface_address}{\N^(\d+)\.(\d+)\.(\d+)\.(\d+)$\N}{\$4\.\$3\.\$2\.\$1}}.ip-port.torhosts.nighteffect.us
log_message = This connection is coming from a tor node that allows
exiting to this ip/port combination
The ACL simply logs the connection, it doesn't perform a rejection, or
adding a header to the message or anything else. That part is left to
the reader or the exim users mailing list.
It was made slightly more difficult to use by the fact that I had to
reverse the 4 octets of the IP address of the host being connected to. I
understand why this was done though and agree with it.
Just out of interest, why do lookups that return positive results take
such a long time? This is what I typically get:
server:~# time host
20.136.234.85.109.123.123.123.123.ip-port.torhosts.nighteffect.us
20.136.234.85.109.123.123.123.123.ip-port.torhosts.nighteffect.us has address
127.0.0.2
Host 20.136.234.85.109.123.123.123.123.ip-port.torhosts.nighteffect.us not
found: 2(SERVFAIL)
Host 20.136.234.85.109.123.123.123.123.ip-port.torhosts.nighteffect.us not
found: 2(SERVFAIL)
real0m23.451s
user0m0.030s
sys 0m0.010s
The first line of response is pretty quick, then there are long delays
before each SERVFAIL...
If the lookup returns an NXDOMAIN, there are no SERVFAILS so the lookups
are much faster. I'm not a DNS expert so I'm not sure what is happening
that causes the SERVFAIL's...
Thanks,
Mike
Re: ip-port.torhosts.nighteffect.us and exim
On Thu, 26 Apr 2007 08:45:39 -0700 Mike Cardwell
[EMAIL PROTECTED] wrote:
I've been looking into how to use this with Exim4. I just thought
I'd
share it here for the benefit of the archives.
warn dnslists=
$interface_port.${sg{$interface_address}{\N^(\d+)\.(\d+)\.(\d+)\.(\
d+)$\N}{\$4\.\$3\.\$2\.\$1}}.ip-port.torhosts.nighteffect.us
log_message = This connection is coming from a tor node that
allows exiting to this ip/port combination
The ACL simply logs the connection, it doesn't perform a
rejection, or
adding a header to the message or anything else. That part is left
to
the reader or the exim users mailing list.
It was made slightly more difficult to use by the fact that I had
to
reverse the 4 octets of the IP address of the host being connected
to. I
understand why this was done though and agree with it.
Just out of interest, why do lookups that return positive results
take
such a long time? This is what I typically get:
server:~# time host 20.136.234.85.109.123.123.123.123.ip-
port.torhosts.nighteffect.us
20.136.234.85.109.123.123.123.123.ip-port.torhosts.nighteffect.us
has address 127.0.0.2
Host 20.136.234.85.109.123.123.123.123.ip-
port.torhosts.nighteffect.us not found: 2(SERVFAIL)
Host 20.136.234.85.109.123.123.123.123.ip-
port.torhosts.nighteffect.us not found: 2(SERVFAIL)
real0m23.451s
user0m0.030s
sys 0m0.010s
The first line of response is pretty quick, then there are long
delays
before each SERVFAIL...
If the lookup returns an NXDOMAIN, there are no SERVFAILS so the
lookups
are much faster. I'm not a DNS expert so I'm not sure what is
happening
that causes the SERVFAIL's...
Hi Mike,
There are a couple of things going on here. First, the reason why
you see the first line returned from the 'host' command as
successful, followed by two 'SERVFAIL' lines is that the 'host'
command, by default, sends an 'A' request followed by an ''
(IPv6 Lookup) and 'MX' (Mail Exchanger) request. The DNSEL server
only supports 'A' requests, and so in the case of the second and
third queries, the DNSEL server is actually returning a 'NOTIMP'
(Not Implemented) error message, and your local upstream DNS server
is returning that to you as a 'SERVFAIL' error message. If you run
the 'host' command with the Type flag set, you can prevent 'host'
from sending the '' and 'MX' requests altogether, eliminating
the two error lines. For example, your query could be:
time host -t A 20.136.234.85.109.123.123.123.123.ip-
port.torhosts.nighteffect.us
Second, to address the speed issue, it's likely that your local
upstream DNS server has some method of operation that really slows
things down when there is an error returned from the DNSEL server,
like the two 'NOTIMP' messages I described above. It may be
retrying those same '' and 'MX' requests several times before
returning the 'SERVFAIL' message to you, holding things up a bit.
So, the good news is, the speed issue is probably already gone just
by you using the Type flag with the 'host' command, like I
discussed above. Personally, I know there is no extra delay from
the DNSEL server when it's returning a 'SERVFAIL', 'NOTIMP', or
'NXDOMAIN' message, as opposed to a successful lookup.
If necessary, for troubleshooting, you can easily see where the
delay is occuring by taking your upstream DNS provider out of the
loop temporarily by telling the 'host' command to talk to the DNSEL
server directly. So, you could do this (If you still wanted it to
do the 'A', '', and 'MX' requests:
time host 20.136.234.85.109.123.123.123.123.ip-
port.torhosts.nighteffect.us 216.55.190.201
Or do this (To exclude the '' and 'MX' requests):
time host -t A 20.136.234.85.109.123.123.123.123.ip-
port.torhosts.nighteffect.us 216.55.190.201
This will let you see the real speed that the DNSEL server is
responding with.
Please let me know if you have any other questions. I hope that
helped!
Best regards,
Joe Kowalski
Re: Accept-encoding: gzip
--- Mike Cardwell [EMAIL PROTECTED] wrote:
Or am I missing something?
Mike
Yes, you are missing something...and that is header
munging. If you use compression then the headers
can/may not be munged (spoofed and modified) as far as
I understand.
I do all my header munging (Firefox browser) via.
about:config and extensions, some people use Privoxy,
etc.
This is my compression setting in about:config, it
disables all compression:
network.http.accept-encoding
{gzip;q=0,deflate;q=0,compress;q=0}
Regards
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Accept-encoding: gzip
--- light zoo [EMAIL PROTECTED] wrote: --- Mike Cardwell [EMAIL PROTECTED] wrote: Or am I missing something? Mike Yes, you are missing something...and that is header munging. If you use compression then the headers can/may not be munged (spoofed and modified) as far as I understand. err...my bad. I just re-read your original email and realized your not referring to browser accept encoding. Regards, __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Accept-encoding: gzip
On Thu, Apr 26, 2007 at 11:57:17AM +0100, Mike Cardwell wrote: As a directory mirror, current requests for the mirror data cause about 2.7MB of data transfer. If the data could be delivered compressed with gzip that could significantly reduce the transfered data... Agreed. That's why we do it already. :) Search dir-spec.txt for .z. (We use zlib, not gzip, for portability reasons. But it's close enough.) Also, almost nobody fetches the v1 directory anymore (the big one you describe above). Most people (I hope) are using the v2 directory design at this point, which was introduced in Tor 0.1.1.x. --Roger
Re: Accept-encoding: gzip
light zoo [EMAIL PROTECTED] wrote:
--- Mike Cardwell [EMAIL PROTECTED] wrote:
Or am I missing something?
Mike
Yes, you are missing something...and that is header
munging. If you use compression then the headers
can/may not be munged (spoofed and modified) as far as
I understand.
The Accept-Encoding header doesn't affect the encoding
of the headers, so there's no reason why it should make a
difference for header modifications.
I do all my header munging (Firefox browser) via.
about:config and extensions, some people use Privoxy,
etc.
This is my compression setting in about:config, it
disables all compression:
network.http.accept-encoding
{gzip;q=0,deflate;q=0,compress;q=0}
I don't think so. It certainly makes fingerprinting
your requests easier, though.
If you don't want to receive compressed content,
you should either set the Accept-Encoding
header to identity, or send no Accept-Encoding
header at all.
Have a look at section 3.5 Content Codings
in: http://ietf.org/rfc/rfc2616.txt
if you're interested in the details.
Of course if there is no reason not to accept
compressed content, it makes sense to just leave
the client's encoding settings alone.
Fabian
signature.asc
Description: PGP signature
Which node is this?
I connected to some random exit node. Its IP was / is 85.214.71.55 I can't find its name to use it again. I've already checked list of ALL nodes and it simply aint there. Nickname, plese. PS: Does anyone know is there a list where I can see curent speed / bandwith of all nodes? Thanks. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Tor nodes blocked by e-gold
Hi, Since 24 hours, e-gold has decided to block all TOR nodes, and not only. In fact they check 3 spam databases and if the user's IP is in one of them, e-gold just declines any operation, people cannot even login into their accounts. There are a few things here: It is the first time I see a website blocking IP that appear in SPAM databases! Spam is, as far as I know, an EMAIL problem, so why would a domain block surfing from these IP? About TOR particularly, I feel very strange that all exit nodes would be listed in spam databases, as most of them (if not all) don't accept sending mail requests. That is why I rather believe that e-gold in fact fetches the TOR exit nodes list, and directly block their IP addresses. A friend, connecting from his home in Germany without TOR, without any proxy, cannot enter his account as his IP address (a dynamic one from a dialup provider) was listed 2 months ago for spam!!! A few people are already complaining that they cannot get into their accounts, and so their money seems to be lost! E-gold was already known to block accounts without any warning and explanations, recently blocked accounts of all Iranian people and KEPT their funds, now they automatize the scam process! E-gold seems to be the next (or TODAY'S) major scam of the internet! F44
