Re: directory authority/authorities need(s) updating?
Last night I reported here that the directory authorities are in disagreement over client-versions and server-versions. Tonight they are still in disagreement. The consensus documents still fail to list any development branch versions later than 0.2.0.15-alpha as server-versions. When will the directory authority operators correct these two problems? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: Tor operator raided in Finland
[EMAIL PROTECTED] schrieb: if you use a transparent proxy plus a provider proxy as parent proxy for your TOR server, you can simply avoid that ;-) To be absolutely sure, you can restrict the TOR output to port 80 and and use transparent http proxying to port 80, plus a provider proxy as parent proxy. I disagree here. Provider proxies usually keep their request logs and they are fully able to find out from which customer IP the request originated. So, sure, the police asks the provider for the customer of their proxy IP. The provider will not be dumb and notice, that is one of his own IPs and will quite probably tell the police about the proxy and that they can find out the customer (and eventually do so). You add a layer of obscurity, but you are not absolutely sure.
Re: Tor operator raided in Finland
Hi, if you use a transparent proxy plus a provider proxy as parent proxy for your TOR server, you can simply avoid that ;-) To be absolutely sure, you can restrict the TOR output to port 80 and and use transparent http proxying to port 80, plus a provider proxy as parent proxy. I disagree here. Provider proxies usually keep their request logs and they are fully able to find out from which customer IP the request originated. So, sure, the police asks the provider for the customer of their proxy IP. The provider will not be dumb and notice, that is one of his own IPs and will quite probably tell the police about the proxy and that they can find out the customer (and eventually do so). You add a layer of obscurity, but you are not absolutely sure. yes, not absolutely sure, but up to now only the TCP/IP IP number has been used against TOR server operators in germany, and as far as i know also in other countries. And i'm using two dozens of IP numbers in the headers of my transparent proxy, so it's neither easy nor sure to find the IP number of my internet connection. Another point is that logging has several flaws: The provider proxies do have thousands of connections per second, but the clocks of the computers have an accuracy of about one minute. So without connection tracking, e. g. with cookies, digging in the log data yields unsure results, especially with dynamic IPs. Greets
Re: Tor operator raided in Finland
On Sun, 27 Jan 2008, [EMAIL PROTECTED] wrote: if you use a transparent proxy plus a provider proxy as parent proxy for your TOR server, you can simply avoid that ;-) To be absolutely sure, you can restrict the TOR output to port 80 and and use transparent http proxying to port 80, plus a provider proxy as parent proxy. I disagree here. Provider proxies usually keep their request logs and they are fully able to find out from which customer IP the request originated. So, sure, the police asks the provider for the customer of their proxy IP. The provider will not be dumb and notice, that is one of his own IPs and will quite probably tell the police about the proxy and that they can find out the customer (and eventually do so). You add a layer of obscurity, but you are not absolutely sure. yes, not absolutely sure, but up to now only the TCP/IP IP number has been used against TOR server operators in germany, and as far as i know also in other countries. And i'm using two dozens of IP numbers in the headers of my transparent proxy, so it's neither easy nor sure to find the IP number of my internet connection. Another point is that logging has several flaws: The provider proxies do have thousands of connections per second, but the clocks of the computers have an accuracy of about one minute. So without connection tracking, e. g. with cookies, digging in the log data yields unsure results, especially with dynamic IPs. i'm really not sure what kind of gras you are smoking, but nearly all mails you send just do not contain the truth. people alread told you, that _all_ your - many ip addresses - ip address changes - proxies .. are _useless_, and will not hide your account from your provider or the police. -- Florian Reitmeir
Re: directory authority/authorities need(s) updating?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Bennett wrote: | Last night I reported here that the directory authorities are in | disagreement over client-versions and server-versions. Tonight they are | still in disagreement. The consensus documents still fail to list any | development branch versions later than 0.2.0.15-alpha as server-versions. | When will the directory authority operators correct these two problems? | The same notice shows up in my log after installing a fresh Tor 0.2.0.18-alpha (r13293) around noon today. By the way, if anyone cares: as of today, my node cerebellum is back up! Only as a relay for now, but better a fast relay than nothing, right? Regards, Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHnJS06GnazsDEIPERApuxAKDbjhPqPvVgbIWDWpcdtq838gxNpgCgo44n 621qPYJJvUsbdWPvdTQOi/k= =oIxS -END PGP SIGNATURE-
Re: Tor operator raided in Finland
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Reitmeir wrote: | | And i'm using two dozens of IP numbers in the headers of my transparent proxy, so | it's neither easy nor sure to find the IP number of my internet connection. | Another point is that logging has several flaws: The provider proxies do have | thousands of connections per second, but the clocks of the computers have an | accuracy of about one minute. So without connection tracking, e. g. with cookies, | digging in the log data yields unsure results, especially with dynamic IPs. | | i'm really not sure what kind of gras you are smoking, but nearly all mails | you send just do not contain the truth. | | people alread told you, that _all_ your | - many ip addresses | - ip address changes | - proxies .. | | are _useless_, and will not hide your account from your provider or the | police. | Hey, let's try not to tear each other to shreds here, we're all on the same team. And btw, noone ever claimed that a provider proxy would hide your identity from anyone. It's just one more step law enforcement has to go to get to you, or at least a little more money they have to spend. Digging through logs can be very time- and ressource-consuming. And I disagree on your view about the use of (non-provider) proxies in general to route your tor exit traffic through. As dr no pointed out, many sites log only the IP address, not any Forwarded-For or similar headers. So while those proxies cannot be *trusted* to provide any level of obscurity or anonymity, they *might* with luck proove to be a dead end (or at least a serious obstacle) for investigations. Especially if they are in another country. Again, just to make sure noone misunderstands it: none of this provides any security (for the tor node operator) for certain. But it decreases your chances to get harrassed by law enforcement. Maybe just slightly, but it does. Correct me if I'm wrong. Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHnJNu6GnazsDEIPERAk6+AKCYGe/jwBqI4IFmJsIr/jXn5ElQPwCgqcPi QPUyTB6h2p1zyeYPfQucGEc= =Zs01 -END PGP SIGNATURE-
Re: Huh?
TorOp schrieb: And what's this about? Jan 27 10:08:00.373 [Notice] Our IP Address has changed from 69.119.206.101 to 212.112.242.159; rebuilding descriptor. Jan 27 10:08:01.595 [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jan 27 10:08:46.068 [Notice] Our IP Address has changed from 212.112.242.159 to 69.119.206.101; rebuilding descriptor. Jan 27 10:08:51.206 [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. That seems to be a (rare) issue with the new alpha versions. A similar log has been posted to this list not too long ago (john smith: unusual connection activity?). Note that *both* IPs point to a tor-node: Zippy (MybKsCAd5bQuzF48aFY3JyuOjxs IGJmo96Yu7liu1Y9xM8jSEV82Jk) and maximator (+pyyTwuDM1sEKAOFYKJM2GYdF2c /zMSZTixMZpKvzJjBa0siBJ8O1U), both of which were set up today according to the directory http://moria.seul.org:9032/tor/status/authority You were/are not by any chance running a second tor server by the name of maximator? If not, developement must be made aware of this issue. Regards, Andrew -- Mails go unsigned, unencrypted for now because of problems earlier today.
Re: Huh?
Andrew wrote: TorOp schrieb: And what's this about? Jan 27 10:08:00.373 [Notice] Our IP Address has changed from 69.119.206.101 to 212.112.242.159; rebuilding descriptor. Jan 27 10:08:01.595 [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jan 27 10:08:46.068 [Notice] Our IP Address has changed from 212.112.242.159 to 69.119.206.101; rebuilding descriptor. Jan 27 10:08:51.206 [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. That seems to be a (rare) issue with the new alpha versions. A similar log has been posted to this list not too long ago (john smith: unusual connection activity?). Note that *both* IPs point to a tor-node: Zippy (MybKsCAd5bQuzF48aFY3JyuOjxs IGJmo96Yu7liu1Y9xM8jSEV82Jk) and maximator (+pyyTwuDM1sEKAOFYKJM2GYdF2c /zMSZTixMZpKvzJjBa0siBJ8O1U), both of which were set up today according to the directory http://moria.seul.org:9032/tor/status/authority You were/are not by any chance running a second tor server by the name of maximator? If not, developement must be made aware of this issue. Regards, Andrew No, I'm only running one node, and the name has always been Zippy. I am running on a part-time basis, about 14 hours a day, but that's the way I've always run it.
Re: Tor operator raided in Finland
Hi, ... As dr no pointed out, many sites log only the IP address, not any Forwarded-For or similar headers. So while those proxies cannot be *trusted* to provide any level of obscurity or anonymity, they *might* with luck proove to be a dead end (or at least a serious obstacle) for investigations. Especially if they are in another country. Again, just to make sure noone misunderstands it: none of this provides any security (for the tor node operator) for certain. But it decreases your chances to get harrassed by law enforcement. Maybe just slightly, but it does. Yes and because in germany there is no logging at the proxy servers (maybe in 2009 this will change) it increases my chance significant. And another point is that the HTTP headers can be simply faked (filled with the content you want) and send from via an open proxy (which does not modify the headers), and that the headers are not unique: When i download with wget and specify a proxy, the transparent proxying produces TWO X-Forwarded-For-Headers, not a concatenation! So logging and evaluating the HTTP headers makes things more complicated but not more safe for identification. I think that switching from identification via TCP/IP IP number to header number(s) would cause mass abuse via open proxies and would be used for indirect DDNS attacks with the TCP/IP IP number of the victim in the header(s), e. g. for blacklisting. Greets
Re: Huh?
On Sun, 27 Jan 2008 10:42:29 -0500 TorOp [EMAIL PROTECTED] wrote: I just upgraded to 0.2.0.17 and didn't see an announcement of 0.2.0.18, which I guess I'll install tonight. Jan 27 10:07:38.882 [Warning] Please upgrade! This version of Tor (0.2.0.17-alpha) is not recommended, according to the directory authorities. Recommended versions are: 0.1.2.19,0.2.0.11-alpha,0.2.0.12-alpha,0.2.0.15-alpha,0.2.0.18-alpha Jan 27 10:07:47.034 [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jan 27 10:07:52.652 [Notice] Performing bandwidth self-test...done. Yes, that's what I've reported twice already on this list. Thus far, it appears that only Peter Palfrader has corrected the information that his directory authority server dishes out. The others are all still wrong and in general disagreement with each other. And what's this about? Jan 27 10:08:00.373 [Notice] Our IP Address has changed from 69.119.206.101 to 212.112.242.159; rebuilding descriptor. Jan 27 10:08:01.595 [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jan 27 10:08:46.068 [Notice] Our IP Address has changed from 212.112.242.159 to 69.119.206.101; rebuilding descriptor. Jan 27 10:08:51.206 [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. This bug was pointed out by someone on this list recently, and Roger Dingledine responded with his thoughts on how tor was probably fooling itself. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: directory authority/authorities need(s) updating?
On Sun, 27 Jan 2008 15:27:01 +0100 Andrew [EMAIL PROTECTED] wrote: Scott Bennett wrote: | Last night I reported here that the directory authorities are in | disagreement over client-versions and server-versions. Tonight they are | still in disagreement. The consensus documents still fail to list any | development branch versions later than 0.2.0.15-alpha as server-versions. | When will the directory authority operators correct these two problems? | The same notice shows up in my log after installing a fresh Tor 0.2.0.18-alpha (r13293) around noon today. The latest consensus file appears to have 0.2.0.18-alpha listed as a recommended server version, but not 0.2.0.16-alpha or 0.2.0.17-alpha, even though it still lists 0.2.0.11-alpha, 0.2.0.12-alpha, and 0.2.0.15-alpha. Also, the individual status documents are still in considerable disagreement with each other. Are the directory authority operators getting careless? By the way, if anyone cares: as of today, my node cerebellum is back up! Only as a relay for now, but better a fast relay than nothing, right? Welcome back! Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: Huh?
On Sun, Jan 27, 2008 at 01:44:38PM -0600, [EMAIL PROTECTED] wrote 2.2K bytes in 42 lines about: : Yes, that's what I've reported twice already on this list. Thus far, : it appears that only Peter Palfrader has corrected the information that his : directory authority server dishes out. The others are all still wrong and : in general disagreement with each other. Please remember the directory authorities are also run by volunteers. I know 2 of them are currently traveling. -- Andrew
Re: directory authority/authorities need(s) updating?
Scott Bennett schrieb: The latest consensus file appears to have 0.2.0.18-alpha listed as a recommended server version, but not 0.2.0.16-alpha or 0.2.0.17-alpha, even though it still lists 0.2.0.11-alpha, 0.2.0.12-alpha, and 0.2.0.15-alpha. Also, the individual status documents are still in considerable disagreement with each other. Are the directory authority operators getting careless? Mhmm. I think, 16-alpha missed a file in the release and 17-alpha had a huge memory leak, I think, it is sane no to recommend them. 18-alpha is different, but it is quite new, I would not be surprised if it is recommended not until a few days in the wild, but I don't know the policy about that.
another unusual connection
greetings! another recurrence of the same type of unusual connection. i include the time the server started in the log below. the connection through 212.112.242.159 persists for a much longer period of time on this occassion (the 'scrubbed' connection did not occur last time). Jan 27 16:25:40.562 [Notice] Performing bandwidth self-test...done. Jan 27 21:33:37.562 [Notice] Our IP Address has changed from 87.194.38.72 to 212.112.242.159; rebuilding descriptor. Jan 27 21:33:41.984 [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jan 27 21:35:01.921 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up. Jan 27 21:54:04.296 [Notice] Our IP Address has changed from 212.112.242.159 to 87.194.38.72; rebuilding descriptor. Jan 27 21:54:12.687 [Notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. on this occassion I accessed my web browser [firefox 2.0.0.11] when the above connection occurred. regards, john smith
Re: directory authority/authorities need(s) updating?
On Sun, Jan 27, 2008 at 09:02:28PM +0100, Dominik Schaefer wrote: Scott Bennett schrieb: The latest consensus file appears to have 0.2.0.18-alpha listed as a recommended server version, but not 0.2.0.16-alpha or 0.2.0.17-alpha, even though it still lists 0.2.0.11-alpha, 0.2.0.12-alpha, and 0.2.0.15-alpha. Also, the individual status documents are still in considerable disagreement with each other. Are the directory authority operators getting careless? Mhmm. I think, 16-alpha missed a file in the release and 17-alpha had a huge memory leak, I think, it is sane no to recommend them. Right. I dropped 0.2.0.16-alpha and 0.2.0.17-alpha from recommended server versions for the reasons you cite. Any server running 0.2.0.17-alpha is going to bloat to the point that it endangers other processes on the machine. There are actually only three v2 authorities that recommend versions: moria1, moria2, and tor26. And I believe just two of these (moria1 and tor26) are the sole v3 authorities that recommend versions. So Scott, don't worry too much about the careless directory operators, especially since we haven't ramped up to having more versioning authorities yet. Our goal isn't to always keep them perfectly in sync anyway -- the goal is to have the majority opinion be a reasonable one. 18-alpha is different, but it is quite new, I would not be surprised if it is recommended not until a few days in the wild, but I don't know the policy about that. My Internet is not very good for this week, so I figured I'd push out 0.2.0.18-alpha (and change recommended versions) before I disappeared. You can read its ChangeLog entry if you want a sneak preview; eventually I'll send an official announce about it. Hope that helps, --Roger
Re: another unusual connection
On Sun, Jan 27, 2008 at 10:42:14PM +, john smith wrote: another recurrence of the same type of unusual connection. i include the time the server started in the log below. the connection through 212.112.242.159 persists for a much longer period of time on this occassion (the 'scrubbed' connection did not occur last time). Neat. So it was 212.112.242.159 in both cases? New theory: in rare cases, Tor servers (like maximator) lie to directory clients about what IP address they appear to have, due to iptables confusion or something similar. More specifically, it claims that everybody looks like itself. Then Tor servers that don't know their own address get suckered into thinking they switched. If this is actually the bug, I'll have to ponder how to fix it well. We could require several places to agree before we think we should switch; but that would slow down reaction times considerably. We could only believe answers from authorities; but I don't want to preclude better load balancing. We could ignore it when we ask a directory mirror at IP address X and he says we look like we're coming from IP address X; that's probably a good idea, and I should add a check for this. Then we can see if that check ever triggers. Please let me know if it happens more (or if other people experience it and can provide more details!), and maybe we'll narrow in further. Thanks, --Roger
How does tor encrypt my data?
Inspired by the principle of tor, we intend to develop a distributed data base which could maintain privacy preserving. But I still have some questions about how does tor work, especially how does it encrypt my data? We know that there is an entrance node and an exit node in a path, cleartext is sent out from the exit node to the destination that we are aimed at. If so, my original cleartext could be revealed to the exit node? If my data is encrypted on my PC by the tor I runned, how does the exit node decrypt the ciphered text? How does it get the decrypt key? Another question is what kind of cryptology algorithm tor uses, RSA? or others? Thank you very much for replying!!!
Re: How to remove some useless nodes
On Jan 27, 2008 11:08 AM, Kraktus [EMAIL PROTECTED] wrote:
You can add
ExcludeNodes NodeName1, NodeName2
to your torrc, where the NodeName1, etc. are the names of Chinese exit
nodes that you are aware of. However, you much disallow each Chinese
node separately; you can't exclude by country.
A crude approach would be to write a script that checks
[vidalia-config-directory]\geoip-cache for IP addresses located in
China, and then extract fingerprints of the Tor nodes on those IPs
from [tor-config-directory]\cached-descriptors to build up your
ExcludeNodes list.
The enclosed perl script does just this. It should be self-explanatory
enough. It produces one ExcludeNodes line to be included in your
torrc file.
Instead of the geoip-cache file, you can also use country IP blocks
from www.ipdeny.com to match IP to country.
Yet another alternative using public tor status pages was discussed on
this list:
http://archives.seul.org/or/talk/Jul-2006/msg00079.html
Cheers,
John
#!/usr/bin/perl
# Usage
if (@ARGV != 3) {
print Usage: $ENV{'_'} [2-letter-country-code] [descriptors-file]
[geoip-file] \n;
exit(1);
}
$ARGV[0] = uc($ARGV[0]);
# Build ip-to-country hash table from geoip cache
open(GEOIP,$ARGV[2]);
while (GEOIP) {
($ip,undef,undef,$country,undef) = split(/,/);
$geoip{$ip} = $country;
}
# Parse descriptor file and extract fingerprints
open(DESC,$ARGV[1]);
$switch = false;
while (DESC) {
chomp;
@params = split(/ /);
if ($params[0] eq 'router') {
$switch = $geoip{$params[2]} eq $ARGV[0];
} elsif ($switch $params[0] eq 'opt' $params[1] eq 'fingerprint') {
push(@exclude,'$' . join('',@params[2 .. $#params]));
}
}
print 'ExcludeNodes ',join(',',@exclude),\n;
Re: directory authority/authorities need(s) updating?
On Sun, 27 Jan 2008 22:50:50 -0500 Roger Dingledine [EMAIL PROTECTED] wrote: On Sun, Jan 27, 2008 at 09:02:28PM +0100, Dominik Schaefer wrote: Scott Bennett schrieb: The latest consensus file appears to have 0.2.0.18-alpha listed as a recommended server version, but not 0.2.0.16-alpha or 0.2.0.17-alpha, even though it still lists 0.2.0.11-alpha, 0.2.0.12-alpha, and 0.2.0.15-alpha. Also, the individual status documents are still in considerable disagreement with each other. Are the directory authority operators getting careless? Mhmm. I think, 16-alpha missed a file in the release and 17-alpha had a huge memory leak, I think, it is sane no to recommend them. Right. I dropped 0.2.0.16-alpha and 0.2.0.17-alpha from recommended server versions for the reasons you cite. Any server running 0.2.0.17-alpha is going to bloat to the point that it endangers other processes on the machine. Really! How long does it take to see this leak? Does the server have to be doing anything in special (e.g., involved in hidden services, being a directory mirror) to trigger the leak? I've been running 0.2.0.17-alpha since I first noticed in was available, at which time I think it had only been available for a day or two. I haven't yet seen the problem. The current instance on my machine has been running about 45.5 hours so far. It appears to be using about 3 MB less right now than it was using around nine hours ago. As far as I can recall, its memory usage has been within a few MB of what it has right now all the time. It sometimes goes up a little, and it sometimes goes down a little. It has never given me cause to suspect a leak. There are actually only three v2 authorities that recommend versions: moria1, moria2, and tor26. And I believe just two of these (moria1 and tor26) are the sole v3 authorities that recommend versions. Does that mean that if one goes down, we can't get a majority opinion on versions? So Scott, don't worry too much about the careless directory operators, especially since we haven't ramped up to having more versioning authorities yet. Our goal isn't to always keep them perfectly in sync anyway -- the goal is to have the majority opinion be a reasonable one. Okay. Thanks for the news. 18-alpha is different, but it is quite new, I would not be surprised if it is recommended not until a few days in the wild, but I don't know the policy about that. My Internet is not very good for this week, so I figured I'd push out 0.2.0.18-alpha (and change recommended versions) before I disappeared. You can read its ChangeLog entry if you want a sneak preview; eventually I'll send an official announce about it. Okay. I just got it late last night and haven't yet had a chance to do anything with it beyond unpacking it. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
