Re: [tor-relays] Network Scan through Tor Exit Node (Port 80)
On Sat, 26 Feb 2011 12:13:53 -0800 Chris Palmer <chris@eff.org> wrote:
On Feb 26, 2011, at 9:53 AM, mick wrote:
No reputable security researcher would a) scan a network without that network owner's explicit permission, nor b) use tor for that scan.
Lots of reputable security researchers who scan the entire internet without getting permission. You can't get permission from every operator in the world, but you still need to do good and interesting research. Examples of reputable researchers who have scanned the whole internet include Dan Bernstein, Dan Kaminsky, and EFF. (At least I think we're reputable. :) ) I don't know for sure, but I can't imagine Arbor, CAIDA, and Renesys can do their jobs without scanning the internet.
Well, as I've just finished describing in another topic here, I treat scanning of my system as attempted security breaches. Such scans will not elicit any apparent response from my system, except that the scanner's IP address will shortly be added to my "block" file, which will deny all future access to my tor node's ORPort and DirPort.
Using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable.
I disagree and, as noted above, treat that as a cracking attempt. tor nodes that you abuse in such fashion will continue to function by the means described below, provided they are listed in the current consensus document. My current procedures are described in the next two paragraphs. However, your implication quoted above that EFF has/does/will abuse tor exits in this manner suggests I may have to modify my treatment of tor exits from which your scans emerge, given the increased likelihood that the offenses did not originate from the exit node's system and that the exit node was instead a victim as well. Nevertheless, your scans will not get responses from my system, except for connection attempts to the ORPort or the DirPort. First, I have set the sysctl variable called net.inet.tcp.blackhole to 2, which causes the kernel to drop all incoming packets addressed to closed ports. The IP addresses of tor nodes, including exit nodes, listed in the cached-consensus file on my system are placed into a "pass" file every 30 minutes, which temporarily exempts them from being checked against the "block" file. It is temporary in that the exemption lasts for 30 minutes only, although it will be exempted for another 30 minutes whenever the address exists in the cached-consensus file at the time the "pass" file is rebuilt. Anyone who may be concerned that their IP address or address range might be listed in my "block" file is welcome to write to me to inquire about it. If it is, then I will offer to remove the block on an indefinitely probationary basis. However, if I encounter the same IP address in my pf log again, then I will block the address permanently. Frankly, I think it's appalling that a previous sponsor organization for the tor project should turn on the tor network in the fashion you've confessed here that it has. I'm tempted to dig out all of the EFF IP address ranges and block them permanently, just as a matter of principle, although it would obviously have little real effect upon your organization. No wonder so many of us have run afoul of our ISPs when trying to run exit nodes when even EFF is trying to spoil the tor network for us. Who needs enemies with "friends" like EFF? 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 * **********************************************************************
On 03/08/2011 02:04 AM, Scott Bennett wrote:
Frankly, I think it's appalling that a previous sponsor organization for the tor project should turn on the tor network in the fashion you've confessed here that it has. I'm tempted to dig out all of the EFF IP address ranges and block them permanently, just as a matter of principle, although it would obviously have little real effect upon your organization. No wonder so many of us have run afoul of our ISPs when trying to run exit nodes when even EFF is trying to spoil the tor network for us. Who needs enemies with "friends" like EFF?
Do you understand the research we are doing? Do you know technically what we have done, and what we hope to do, and what the impact has been and will be? If you don't know yet, please check out our page: https://www.eff.org/observatory If you have seen and understood that, please explain what about it you find so objectionable. Note also that the Tor Project is using our database to improve Tor itself, too. We are working to make the internet safer for everyone. -- Chris Palmer Technology Director, Electronic Frontier Foundation https://www.eff.org/code
On Tue, 8 Mar 2011 04:04:13 -0600 (CST) Scott Bennett <bennett@cs.niu.edu> wrote:
On Sat, 26 Feb 2011 12:13:53 -0800 Chris Palmer <chris@eff.org> wrote:
On Feb 26, 2011, at 9:53 AM, mick wrote:
No reputable security researcher would a) scan a network without that network owner's explicit permission, nor b) use tor for that scan.
Lots of reputable security researchers who scan the entire internet without getting permission. You can't get permission from every operator in the world, but you still need to do good and interesting research. Examples of reputable researchers who have scanned the whole internet include Dan Bernstein, Dan Kaminsky, and EFF. (At least I think we're reputable. :) ) I don't know for sure, but I can't imagine Arbor, CAIDA, and Renesys can do their jobs without scanning the internet.
Well, as I've just finished describing in another topic here, I treat scanning of my system as attempted security breaches. Such scans will not elicit any apparent response from my system, except that the scanner's IP address will shortly be added to my "block" file, which will deny all future access to my tor node's ORPort and DirPort.
So all I need to do in order to block a Tor client or bridge from connecting to your Tor relay is send a few SYN packets with forged sender IP addresses? Brilliant move.
Using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable.
I disagree and, as noted above, treat that as a cracking attempt.
Why do you consider a portscan to be an attempt to gain unauthorized access to your computer? Robert Ransom
On Tue, 8 Mar 2011 18:35:12 -0800 Robert Ransom <rransom.8774@gmail.com> wrote:
On Tue, 8 Mar 2011 04:04:13 -0600 (CST) Scott Bennett <bennett@cs.niu.edu> wrote:
On Sat, 26 Feb 2011 12:13:53 -0800 Chris Palmer <chris@eff.org> wrote:
Using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable.
I disagree and, as noted above, treat that as a cracking attempt.
Why do you consider a portscan to be an attempt to gain unauthorized access to your computer?
On second thought, now that you have publicly stated that you have programmed your computer to detect portscans and respond to them by malfunctioning, a portscan itself may very well be an attack on your computer. Robert Ransom
On 3/9/11 3:35 AM, Robert Ransom wrote:
Why do you consider a portscan to be an attempt to gain unauthorized access to your computer?
The management of the portscan it's really a pain, i got my server on Hetzner.de disconnected again due to portscan getting out from my TOR exit node. They are listed in the "Friendly" good ISP for TOR, but you take less than 12hours to manage a portscan ticket they will just cut-off your server and you have to go trough a written and hands-signed declaration to be sent via digitalized pdf or FAX. We *really* need to find a technical way to be able to detect and block outgoing portscan from the TOR exit nodes. Below an example of the report i got from Hetzner about portscan getting out from my TOR exit node: ########################################################################## # Netscan detected from host 88.198.109.35 # ########################################################################## time protocol src_ip src_port dest_ip dest_port --------------------------------------------------------------------------- Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 56392 => 31.65.10.163 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 59470 => 31.65.54.223 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 54086 => 31.65.72.45 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 59950 => 31.65.88.131 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 38952 => 31.65.120.208 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 42653 => 31.66.75.23 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 55963 => 31.66.115.82 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 58100 => 31.66.195.70 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 53933 => 31.66.208.49 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 44360 => 31.66.208.75 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 40767 => 31.66.249.136 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 34733 => 31.67.60.191 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 50122 => 31.67.77.76 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 49062 => 31.67.100.236 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 51349 => 31.67.196.81 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 47977 => 31.67.225.65 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 33600 => 31.68.43.89 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 55763 => 31.68.62.141 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 48964 => 31.68.104.16 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 52435 => 31.69.117.138 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 37726 => 31.69.149.38 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 40678 => 31.70.47.62 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 39276 => 31.70.122.82 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 34060 => 31.70.157.174 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 59382 => 31.70.175.45 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 42583 => 31.71.11.228 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 51358 => 31.71.246.117 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 51179 => 31.72.121.192 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 49689 => 31.72.165.151 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 49958 => 31.72.178.72 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 33015 => 31.73.170.6 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 40535 => 31.73.173.206 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 40190 => 31.73.182.167 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 38007 => 31.73.201.249 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 47829 => 31.74.114.139 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 42451 => 31.74.239.168 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 36958 => 31.75.27.127 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 42734 => 31.75.127.188 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 42298 => 31.75.164.80 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 34054 => 31.75.193.121 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 60265 => 31.76.3.50 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 48796 => 31.76.74.41 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 36588 => 31.76.182.215 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 39682 => 31.76.205.16 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 40542 => 31.77.10.157 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 42494 => 31.77.76.109 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 42061 => 31.77.119.231 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 42950 => 31.77.146.156 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 60724 => 31.77.223.251 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 36208 => 31.77.224.147 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 49522 => 31.78.169.199 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 36339 => 31.78.175.3 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 59629 => 31.80.67.150 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 36172 => 31.80.99.74 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 36496 => 31.80.182.30 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 52575 => 31.80.242.10 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 41079 => 31.81.15.152 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 52872 => 31.81.133.26 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 39720 => 31.81.208.122 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 53889 => 31.82.100.0 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 37307 => 31.82.115.225 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 48091 => 31.82.128.212 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 33158 => 31.82.139.158 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 48170 => 31.83.86.22 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 51846 => 31.83.160.155 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 53818 => 31.84.139.78 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 50961 => 31.84.203.175 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 40926 => 31.85.30.37 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 48615 => 31.85.233.17 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 49893 => 31.86.120.197 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 33616 => 31.86.120.209 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 60852 => 31.86.171.42 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 41752 => 31.87.154.173 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 53469 => 31.87.190.171 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 43784 => 31.88.27.217 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 57287 => 31.89.9.9 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 37264 => 31.89.26.185 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 48953 => 31.89.100.22 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 58038 => 31.89.126.160 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 43601 => 31.90.111.229 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 43007 => 31.90.198.139 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 55715 => 31.91.110.137 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 39617 => 31.91.135.247 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 60766 => 31.91.177.129 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 40362 => 31.92.9.79 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 55762 => 31.92.12.229 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 39595 => 31.92.89.203 443 Tue Mar 8 17:36:29 2011 TCP 88.198.109.35 53314 => 31.92.117.224 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 43721 => 31.92.154.88 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 45939 => 31.92.215.189 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 49305 => 31.93.171.230 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 49708 => 31.93.228.184 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 37831 => 31.94.13.26 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 33898 => 31.94.50.56 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 37904 => 31.94.141.127 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 37748 => 31.94.146.165 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 42008 => 31.94.186.77 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 44779 => 31.94.217.247 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 50810 => 46.122.153.78 443 Tue Mar 8 17:36:30 2011 TCP 88.198.109.35 49972 => 46.122.182.172 443
Why do you consider a portscan to be an attempt to gain unauthorized
access to your computer?
The management of the portscan it's really a pain, i got my server on Hetzner.de disconnected again due to portscan getting out from my TOR exit node.
We *really* need to find a technical way to be able to detect and block outgoing portscan from the TOR exit nodes.
As Tor exits are a curious mix of common carrier and end user in this case... If of concern, I'd simply suggest the application of an IDS and blocking system to your exit traffic. Bro, Snort, filters, some other applicable system, whatever it may be. There is certainly precedent for doing so in a common carrier agnostic fashion in other areas of the internet, no reason that Tor must be any different. And no reason that such application would have any adverse affect on the underlying principles of Tor to which we all might ascribe.
Am 09.03.2011 09:20, schrieb Fabio Pietrosanti (naif):
We *really* need to find a technical way to be able to detect and block outgoing portscan from the TOR exit nodes.
this might cause a lot of collateral damage. I don't think it's a good idea. How can we distinguish between legitimate Tor exit traffic and a someone scanning whole networks for certain applications? Imo we should concentrate our efforts to IPv6 support. regards Olaf
On 3/9/11 10:02 AM, Olaf Selke wrote:
Am 09.03.2011 09:20, schrieb Fabio Pietrosanti (naif):
We *really* need to find a technical way to be able to detect and block outgoing portscan from the TOR exit nodes.
this might cause a lot of collateral damage. I don't think it's a good idea. How can we distinguish between legitimate Tor exit traffic and a someone scanning whole networks for certain applications?
That's the point, how to do it in the right way without creating collateral damage. Detecting a portscan is not rocket science, but the problem is imho: - detection logic (based on destination and not on source of scan) - tuning of detection logic (for example how wide the destination can be) - dynamic blocking (which destination netblock to block? Several portscan randomize across a Class-B network) - tuning of dynamic blocking (for how much time to block destination networks?) And in such extremely finely tuned situation, block or strongly-rate-limit the traffic to the destination? Imho those are still unsolved technical problem because 100% of portscan detection system are based on detecting "a single source of portscan and block the source of portscan". In that case "we are the source of portscan" and the destination can be "randomized across a Class-B network". So sounds more complex than what appear being able to block TOR exit outgoing portscan in proper and clean way. -naif http://infosecurity.ch
On Wednesday 09 March 2011 03:20:03 Fabio Pietrosanti (naif) wrote:
On 3/9/11 3:35 AM, Robert Ransom wrote: We *really* need to find a technical way to be able to detect and block outgoing portscan from the TOR exit nodes.
How is the ISP detecting the portscan? Does it log failed connections? Does it look for lots of addresses accessed in a small IP address range? On Wednesday 09 March 2011 04:19:54 Fabio Pietrosanti (naif) wrote:
And in such extremely finely tuned situation, block or strongly-rate-limit the traffic to the destination?
Rate-limiting the circuit (to one packet every 1 to 5 seconds) is something to try. We could divide the number of failed connections by (number of connection attempts +5), and if that goes above 50%, throttle the circuit.
On Tue, 8 Mar 2011 18:35:12 -0800 Robert Ransom <rransom.8774@gmail.com> allegedly wrote:
On Tue, 8 Mar 2011 04:04:13 -0600 (CST) Scott Bennett <bennett@cs.niu.edu> wrote:
[much snipped]
Using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable.
I disagree and, as noted above, treat that as a cracking attempt.
Why do you consider a portscan to be an attempt to gain unauthorized access to your computer?
Robert Ransom
I'm with Scott. Whilst I don't necessarily agree that a portscan is an attempt to gain unauthorised access, I don't like them for the following reasons: - they are /indicative/ of reconnaisance activity which may be a precursor to later attack. - they tend to irritate ISPs (and corporations which log such activity). If the scan comes from a system for which I am responsible, they will likely vent that irritation at me. - scans /can/ and /do/ cause DOS on some devices. A cursory search of bugtraq archives should unearth plenty of examples. Some examples I am aware of (though admittedly unlikely to reachable from a Tor exit node) are the HP procurve switch, some Jetdirect printers, some Netgear DSL routers etc. As I have pointed out before, this is illegal in the UK (our legislation being "laughably absurd" doesn't stop it being the law.) And as Scott said, I don't see why EFF should place the operators of Tor nodes at risk by using Tor as a scanning tool. Mick --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
On 3/9/11 5:17 PM, mick wrote:
I'm with Scott. Whilst I don't necessarily agree that a portscan is an attempt to gain unauthorised access, I don't like them for the following reasons:
- they are /indicative/ of reconnaisance activity which may be a precursor to later attack.
- they tend to irritate ISPs (and corporations which log such activity). If the scan comes from a system for which I am responsible, they will likely vent that irritation at me.
- scans /can/ and /do/ cause DOS on some devices. A cursory search of bugtraq archives should unearth plenty of examples. Some examples I am aware of (though admittedly unlikely to reachable from a Tor exit node) are the HP procurve switch, some Jetdirect printers, some Netgear DSL routers etc. As I have pointed out before, this is illegal in the UK (our legislation being "laughably absurd" doesn't stop it being the law.)
I fully underline what's told by Mike, it's a dangerous topic, but being able to implement some kind of filering at exit node is required. Probably implementing something as an external tool is better to avoid introducing "filtering logic" directly into TOR project. Do we want to try to setup a working group on this? -naif http://infosecurity.ch
hi I m having problem in running tor since last 1 week. I am getting the following log. Mar 08 14:17:17.950 [Notice] Initialized libevent version 1.4.14-stable using method win32. Good. Mar 08 14:17:17.950 [Notice] Opening Socks listener on 127.0.0.1:9050 Mar 08 14:17:17.950 [Notice] Opening Control listener on 127.0.0.1:9051 Mar 08 14:17:17.950 [Notice] Parsing GEOIP file. Mar 08 14:17:22.831 [Notice] No current certificate known for authority moria1; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority tor26; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority dizum; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority ides; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority gabelmoo; launching request. Mar 08 14:17:22.832 [Notice] No current certificate known for authority dannenberg; launching request. Mar 08 14:17:22.832 [Notice] No current certificate known for authority urras; launching request. Mar 08 14:17:22.832 [Notice] No current certificate known for authority maatuska; launching request. Mar 08 14:17:42.440 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 3; recommendation warn) Mar 08 14:18:03.172 [Notice] Tor v0.2.1.30. This is experimental software. Do not rely on it for strong anonymity. (Running on Very recent version of Windows [major=6,minor=1] [workstation] {terminal services, single user}) Mar 08 14:18:03.284 [Notice] Initialized libevent version 1.4.14-stable using method win32. Good. Mar 08 14:18:03.285 [Notice] Opening Socks listener on 127.0.0.1:9050 Mar 08 14:18:03.285 [Notice] Opening Control listener on 127.0.0.1:9051 Mar 08 14:18:03.285 [Notice] Parsing GEOIP file. Mar 08 14:18:08.857 [Notice] No current certificate known for authority moria1; launching request. Mar 08 14:18:08.857 [Notice] No current certificate known for authority tor26; launching request. Mar 08 14:18:08.857 [Notice] No current certificate known for authority dizum; launching request. Mar 08 14:18:08.857 [Notice] No current certificate known for authority ides; launching request. Mar 08 14:18:08.857 [Notice] No current certificate known for authority gabelmoo; launching request. Mar 08 14:18:08.858 [Notice] No current certificate known for authority dannenberg; launching request. Mar 08 14:18:08.858 [Notice] No current certificate known for authority urras; launching request. Mar 08 14:18:08.862 [Notice] No current certificate known for authority maatuska; launching request. Mar 08 14:18:29.841 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 2; recommendation warn) Mar 08 14:20:09.428 [Notice] No current certificate known for authority moria1; launching request. Mar 08 14:20:09.467 [Notice] No current certificate known for authority tor26; launching request. Mar 08 14:20:09.472 [Notice] No current certificate known for authority dizum; launching request. Mar 08 14:20:09.477 [Notice] No current certificate known for authority ides; launching request. Mar 08 14:20:09.482 [Notice] No current certificate known for authority gabelmoo; launching request. Mar 08 14:20:09.486 [Notice] No current certificate known for authority dannenberg; launching request. Mar 08 14:20:09.491 [Notice] No current certificate known for authority urras; launching request. Mar 08 14:20:09.496 [Notice] No current certificate known for authority maatuska; launching request. Mar 08 14:20:30.430 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 3; recommendation warn) Mar 08 14:22:26.329 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again. Mar 08 14:22:59.733 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again. Mar 08 14:23:20.734 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 6; recommendation warn) Mar 08 14:24:26.465 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit) Mar 08 14:24:59.467 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit) Mar 08 14:26:15.483 [Notice] No current certificate known for authority moria1; launching request. Mar 08 14:26:15.486 [Notice] No current certificate known for authority tor26; launching request. Mar 08 14:26:15.492 [Notice] No current certificate known for authority dizum; launching request. Mar 08 14:26:15.492 [Notice] No current certificate known for authority ides; launching request. Mar 08 14:26:15.492 [Notice] No current certificate known for authority gabelmoo; launching request. Mar 08 14:26:15.492 [Notice] No current certificate known for authority dannenberg; launching request. Mar 08 14:26:15.493 [Notice] No current certificate known for authority urras; launching request. Mar 08 14:26:15.493 [Notice] No current certificate known for authority maatuska; launching request. Mar 08 14:26:36.486 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 10; recommendation warn) I am using my university network. My room mate is using the same network & it's working fine in his PC. Please help.
Thus spake Fabio Pietrosanti (naif) (lists@infosecurity.ch):
I fully underline what's told by Mike, it's a dangerous topic, but being able to implement some kind of filering at exit node is required.
Probably implementing something as an external tool is better to avoid introducing "filtering logic" directly into TOR project.
Do we want to try to setup a working group on this?
If you are serious about this, there *must* be some feedback through the Tor protocol to clients who get hit by this censorship. Censorship is a reality everywhere, but that does not mean it is OK to add it to the Tor network for expedience or for marginal gains of Exit bandwidth. Maybe I'm too much of an Amurrican Capitalish, but I do not believe that data centers that impose censorship on Tor Exits deserve any of our collective hosting budgets. Any Exits where censorship is detected can, should, and will receive the BadExit flag, and this includes those that censor for "security reasons". *HOWEVER*, it is in theory possible to provide notification when streams are closed on the fly. The Tor Protocol supports sending the "EXITPOLICY" close reason upstream. The Tor Control Protocol can be extended to allow exits to tell Tor to close streams with this reason. Clients will then automatically, transparently retry their streams at new exits. This ability to transparently route around censorship is the *only* way that it can be acceptable on Tor Exits. And not all forms of IDS can even fit under this model. We must be able to close streams *before* the TCP handshake. We can use circuit correlation to see that one stream on a circuit did something "bad", and then send the EXITPOLICY close reason to all future streams on this circuit. This would also reduce "hacking" attempts and still allow clients to carry on transparently as if nothing ever happened (except a little extra latency). This is not a small project, but it is not an impossible one. The building blocks are all there. If you'd like to discuss this more, we can chat on #tor-dev on irc.oftc.net. It is unlikely that official Tor development time will be spent on this, so be prepared to be ready to hack some code yourself :). It may also be politically unpopular, but that doesn't need to stop you from building it either. -- Mike Perry Mad Computer Scientist fscked.org evil labs
hi I m having problem in running tor since last 1 week. I am getting the following log. Mar 08 14:17:22.832 [Notice] No current certificate known for authority maatuska; launching request. Mar 08 14:17:42.440 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 3; recommendation warn) Mar 08 14:18:03.172 [Notice] Tor v0.2.1.30. This is experimental software. Do not rely on it for strong anonymity. (Running on Very recent version of Windows [major=6,minor=1] [workstation] {terminal services, single user}) Mar 08 14:18:03.284 [Notice] Initialized libevent version 1.4.14-stable using method win32. Good. Mar 08 14:18:03.285 [Notice] Opening Socks listener on 127.0.0.1:9050 Mar 08 14:18:03.285 [Notice] Opening Control listener on 127.0.0.1:9051 Mar 08 14:18:03.285 [Notice] Parsing GEOIP file. Mar 08 14:18:08.857 [Notice] No current certificate known for authority moria1; launching request. Mar 08 14:18:08.857 [Notice] No current certificate known for authority tor26; launching request. Mar 08 14:18:08.857 [Notice] No current certificate known for authority dizum; launching request. Mar 08 14:18:08.857 [Notice] No current certificate known for authority ides; launching request. Mar 08 14:18:08.857 [Notice] No current certificate known for authority gabelmoo; launching request. Mar 08 14:18:08.858 [Notice] No current certificate known for authority dannenberg; launching request. Mar 08 14:18:08.858 [Notice] No current certificate known for authority urras; launching request. Mar 08 14:18:08.862 [Notice] No current certificate known for authority maatuska; launching request. Mar 08 14:18:29.841 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 2; recommendation warn) Mar 08 14:20:09.428 [Notice] No current certificate known for authority moria1; launching request. Mar 08 14:20:09.467 [Notice] No current certificate known for authority tor26; launching request. Mar 08 14:20:09.472 [Notice] No current certificate known for authority dizum; launching request. Mar 08 14:20:09.477 [Notice] No current certificate known for authority ides; launching request. Mar 08 14:20:09.482 [Notice] No current certificate known for authority gabelmoo; launching request. Mar 08 14:20:09.486 [Notice] No current certificate known for authority dannenberg; launching request. Mar 08 14:20:09.491 [Notice] No current certificate known for authority urras; launching request. Mar 08 14:20:09.496 [Notice] No current certificate known for authority maatuska; launching request. Mar 08 14:20:30.430 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 3; recommendation warn) Mar 08 14:22:26.329 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again. Mar 08 14:22:59.733 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again. Mar 08 14:23:20.734 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 6; recommendation warn) Mar 08 14:24:26.465 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit) Mar 08 14:24:59.467 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit) Mar 08 14:26:15.483 [Notice] No current certificate known for authority moria1; launching request. Mar 08 14:26:15.486 [Notice] No current certificate known for authority tor26; launching request. Mar 08 14:26:15.492 [Notice] No current certificate known for authority dizum; launching request. Mar 08 14:26:15.492 [Notice] No current certificate known for authority ides; launching request. Mar 08 14:26:15.492 [Notice] No current certificate known for authority gabelmoo; launching request. Mar 08 14:26:15.492 [Notice] No current certificate known for authority dannenberg; launching request. Mar 08 14:26:15.493 [Notice] No current certificate known for authority urras; launching request. Mar 08 14:26:15.493 [Notice] No current certificate known for authority maatuska; launching request. Mar 08 14:26:36.486 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 10; recommendation warn) I am using my university network. My room mate is using the same network & it's working fine in his PC. Please help.
On Wed, 9 Mar 2011 20:49:17 -0800 prafull moulekhi <prafullmoulekhi90@gmail.com> wrote:
I m having problem in running tor since last 1 week. I am getting the following log.
Mar 08 14:26:36.486 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 10; recommendation warn)
Thanks for the bug report! The 'Notice' messages you listed in your first message did not indicate any problem, but this warning message indicates that your computer cannot reach the directory mirror it is trying to use.
I am using my university network. My room mate is using the same network & it's working fine in his PC.
Is your roommate using a bridge, HTTP proxy, or SOCKS proxy to connect to Tor? (If so, DO NOT tell us the bridge or proxy address; only tell us whether he is using one or not.) Robert Ransom
he is not using any proxy or bridge etc to connect tor. It was working on my PC, but since last week I am facing this problem. Thanks On Wed, Mar 9, 2011 at 9:58 PM, Robert Ransom <rransom.8774@gmail.com>wrote:
On Wed, 9 Mar 2011 20:49:17 -0800 prafull moulekhi <prafullmoulekhi90@gmail.com> wrote:
I m having problem in running tor since last 1 week. I am getting the following log.
Mar 08 14:26:36.486 [Warning] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Socket is not connected [WSAENOTCONN ]; NOROUTE; count 10; recommendation warn)
Thanks for the bug report! The 'Notice' messages you listed in your first message did not indicate any problem, but this warning message indicates that your computer cannot reach the directory mirror it is trying to use.
I am using my university network. My room mate is using the same network & it's working fine in his PC.
Is your roommate using a bridge, HTTP proxy, or SOCKS proxy to connect to Tor? (If so, DO NOT tell us the bridge or proxy address; only tell us whether he is using one or not.)
Robert Ransom
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 03/09/2011 08:17 AM, mick wrote:
And as Scott said, I don't see why EFF should place the operators of Tor nodes at risk by using Tor as a scanning tool.
Again, do you understand what it is we are doing? We are not doing a scan with Nmap set to "aggressive" or "stealthy" on all ports. We are saying hello on port 443, and then saying goodbye. Once. Using normal TCP and TLS handshaking, no tricks. For the good of the internet. -- Chris Palmer Technology Director, Electronic Frontier Foundation https://www.eff.org/code
On 3/9/11 9:45 PM, Chris Palmer wrote:
On 03/09/2011 08:17 AM, mick wrote:
And as Scott said, I don't see why EFF should place the operators of Tor nodes at risk by using Tor as a scanning tool.
Again, do you understand what it is we are doing?
We are not doing a scan with Nmap set to "aggressive" or "stealthy" on all ports.
We are saying hello on port 443, and then saying goodbye. Once. Using normal TCP and TLS handshaking, no tricks. For the good of the internet.
But does i understood that the SSL Observatory scan are done trough TOR nodes? In such case it would be interesting to know which is the algorithm used to distributed the scan across the internet. Depending on how the randomization and distribution across different IPs/netblocks is efficient it may or may not trigger Port Scan Detection systems. If the SSL scan is very well distributed not only at IP layer (which destination IP address) but also at TOR-Circuit level (for example sending a maximum of X packets on each TOR-Circuit) it would for sure not trigger any portscan detector. But maybe there's a bug and the scan and so enough randomized so that they appear like a portscan in some sensible portscan system when getting out to a TOR-exit node? (i don't know) -naif http://infosecurity.ch
On 03/09/2011 01:01 PM, Fabio Pietrosanti (naif) wrote:
But does i understood that the SSL Observatory scan are done trough TOR nodes?
No. The Observatory scans were done from EFF machines in our data center. Our slides and source code and data are available for free. Please check them out. We propose, in the next phase of Observatory research, to distribute the scanning by providing an open source Firefox plugin that would do some scan work. If it saw anything interesting, it would report its results (with user consent, of course) to our collection server through Tor. The purpose of distributed scanning is to get a wider view of the TLS universe, and the purpose of reporting the results through Tor is to allow users to have anonymity even while helping populate the Observatory. Actually scanning through Tor might be nifty, might be useful. But it's not currently in our plan anyway. Mostly my purpose in this thread has been to assert that gentle, non-abusive TCP connections for the purpose of research are gentle, non-abusive, and good for research. Tor is the best overlay network in the world, and that's a handy thing for lots of nice reasons besides the nice reason of anonymity.
In such case it would be interesting to know which is the algorithm used to distributed the scan across the internet.
Our code is open source, and any new code also will be.
Depending on how the randomization and distribution across different IPs/netblocks is efficient it may or may not trigger Port Scan Detection systems.
Right. In any case our goal is to be gentle, not to hide. -- Chris Palmer Technology Director, Electronic Frontier Foundation https://www.eff.org/code
On 3/9/11 11:27 PM, Chris Palmer wrote:
On 03/09/2011 01:01 PM, Fabio Pietrosanti (naif) wrote:
But does i understood that the SSL Observatory scan are done trough TOR nodes? No. The Observatory scans were done from EFF machines in our data center. Our slides and source code and data are available for free. Please check them out. Great! and very great project the SSL Observatory! :-)
I got it, it's just that it started looking a dangerous thread with misunderstanding discussions about portscanning claims on tor maintainer and the SSL Observatory's scans :P I got the point on how TOR could be useful for research providing a lot of different point of view of the internet being able to monitor censorship status, filtering, detect mitm conditions, etc :) Still the issue of evaluating opportunity to reduce claims/disconnection and provide more friendly location/ISP for exit-nodes is there. :( -naif http://infosecurity.ch
On 2011-03-09 21:45, Chris Palmer wrote:
On 03/09/2011 08:17 AM, mick wrote:
And as Scott said, I don't see why EFF should place the operators of Tor nodes at risk by using Tor as a scanning tool.
Again, do you understand what it is we are doing?
We are not doing a scan with Nmap set to "aggressive" or "stealthy" on all ports.
We are saying hello on port 443, and then saying goodbye. Once. Using normal TCP and TLS handshaking, no tricks. For the good of the internet.
That would be enough to get me in trouble with my ISP for performing portscans (if I were running an exit node). Instead of abusing the Tor exit nodes, you could rent some cheap dedicated servers or VPSes to perform your scans from.
On 2011-03-09 21:45, Chris Palmer wrote:
On 03/09/2011 08:17 AM, mick wrote:
And as Scott said, I don't see why EFF should place the operators of Tor nodes at risk by using Tor as a scanning tool.
Again, do you understand what it is we are doing?
We are not doing a scan with Nmap set to "aggressive" or "stealthy" on all ports.
We are saying hello on port 443, and then saying goodbye. Once. Using normal TCP and TLS handshaking, no tricks. For the good of the internet.
That would be enough to get me in trouble with my ISP for performing portscans (if I were running an exit node). Instead of abusing the Tor exit nodes, you could rent some cheap dedicated servers or VPSes to perform your scans from.
On 09.03.2011 22:48, Arjan wrote:
We are saying hello on port 443, and then saying goodbye. Once. Using normal TCP and TLS handshaking, no tricks. For the good of the internet. That would be enough to get me in trouble with my ISP for performing portscans (if I were running an exit node).
How could anyone judge what is a valid action, and what kind of connections are not, if we are already fighting over this on this list? EFF, you are welcome to use our Tor exits if you think it is useful for the Observatory. -- Moritz Bartl https://www.torservers.net/
On 03/09/2011 01:48 PM, Arjan wrote:
We are saying hello on port 443, and then saying goodbye. Once. Using normal TCP and TLS handshaking, no tricks. For the good of the internet.
That would be enough to get me in trouble with my ISP for performing portscans (if I were running an exit node).
And how would you, or anyone else, differentiate that from normal web browsing? -- Chris Palmer Technology Director, Electronic Frontier Foundation https://www.eff.org/code
On Wednesday 09 March 2011 17:20:17 Chris Palmer wrote:
On 03/09/2011 01:48 PM, Arjan wrote:
We are saying hello on port 443, and then saying goodbye. Once. Using normal TCP and TLS handshaking, no tricks. For the good of the internet.
That would be enough to get me in trouble with my ISP for performing portscans (if I were running an exit node).
And how would you, or anyone else, differentiate that from normal web browsing?
If a lot of those connection attempts are going to IP addresses with no host present, or hosts not running a webserver, it looks like portscanning. If almost all of the connection attempts are to webservers that have port 443 open, it looks like normal https web browsing. I have only one external address and only a few ports forwarded, so I can't detect portscans. I have noticed that an attempt to guess passwords on SSH is often, but not always, preceded by a connect and disconnect from the same IP address, which is probably part of a portscan. I don't block addresses that scan ports, but I do block addresses that try to guess passwords (not on the Tor box, just on the other one). The block expires in a day. cmeclax cmeclax
On Wed, 09 Mar 2011 12:45:39 -0800 Chris Palmer <chris@eff.org> allegedly wrote:
On 03/09/2011 08:17 AM, mick wrote:
And as Scott said, I don't see why EFF should place the operators of Tor nodes at risk by using Tor as a scanning tool.
Again, do you understand what it is we are doing?
We are not doing a scan with Nmap set to "aggressive" or "stealthy" on all ports.
We are saying hello on port 443, and then saying goodbye. Once. Using normal TCP and TLS handshaking, no tricks. For the good of the internet.
Chris Yes, I do understand what you are doing, but no, I do not understand why you should need to do this through Tor. And here I confess that I am now confused (not difficult, it happens) because in your email dated 26 Feb you said:- "Lots of reputable security researchers who scan the entire internet without getting permission. You can't get permission from every operator in the world, but you still need to do good and interesting research. Examples of reputable researchers who have scanned the whole internet include Dan Bernstein, Dan Kaminsky, and EFF. (At least I think we're reputable. :) ) I don't know for sure, but I can't imagine Arbor, CAIDA, and Renesys can do their jobs without scanning the internet. Using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable." Which says to me that you are using Tor to do this research. Whilst in your email dated 9 March you say:- "No. The Observatory scans were done from EFF machines in our data center. Our slides and source code and data are available for free. Please check them out." and "Actually scanning through Tor might be nifty, might be useful. But it's not currently in our plan anyway." Which says categorically that you are not using Tor. So which is it? Mick --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
On 03/10/2011 09:10 AM, mick wrote:
Using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable."
Which says to me that you are using Tor to do this research.
No, it says to you that using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable.
So which is it?
The Observatory work was not done through Tor. However, using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable, so I vociferously defend the idea of doing so. -- Chris Palmer Technology Director, Electronic Frontier Foundation https://www.eff.org/code
participants (12)
-
Arjan -
Chris Palmer -
cmeclax-sazri -
Fabio Pietrosanti (naif) -
grarpamp -
mick -
Mike Perry -
Moritz Bartl -
Olaf Selke -
prafull moulekhi -
Robert Ransom -
Scott Bennett