Re: suspicious log warning messages
On Thu, 8 Nov 2007 10:28:30 -0500 Nick Mathewson <[EMAIL PROTECTED]> wrote: >On Thu, Nov 08, 2007 at 07:02:53AM -0600, Scott Bennett wrote: >> Last night my tor server logged some unexpected messages. I've wait= >ed >> about twelve hours to see whether any relevant discussion appeared on this >> list. Thus far, it hasn't, so I'm posting them here in hopes that someone >> will explain what he/she was doing. > [...] >> Nov 07 19:37:24.205 [warn] Not enough good signatures on networkstatus co= >nsensus >> Nov 07 19:37:24.221 [warn] Unable to load consensus directory dowloaded f= >rom server '128.31.0.34:9001' >>=20 >> No more messages of this sort have appeared since the last one shown abov= >e. > >There's a new v3 directory authority, "ides", run by Mike Perry. >Apparently, adding it caused some weird bug to show up in the new >certificate download code. See Flyspray bug 546. > Fair enough. I'm glad it was all in a good cause. :-) Thanks, Nick, for clearing that up. 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: Security concerns/help me understand tor
--- Kyle Williams <[EMAIL PROTECTED]> wrote: > On Nov 8, 2007 8:53 AM, Martin Fick > > On Wed, Nov 07, 2007 at 08:20:37AM -0800, Martin > > Fick wrote: > > > My home router offers an http administration > > > console on port 80 which for obvious security > > > reasons is normally only accessible from the > > > internal facing side of the router. While > > > many of these home routers typically have an > > > internal private IP such as 192.168.1.1 and > > > an external public IP, they sometimes respond > > > to both IPs from the inside and sometimes they > > > even allow access to the administration console > > > on the external IP if it is accessed from the > > > internal side of the router (mine does). This > > > would not normally be a problem, but add a tor > > > exit server to the inside of a home network > > > serviced by such a router and ...you can > > > probably guess where I am going with this. ... > > --- Ruben Garcia <[EMAIL PROTECTED]> wrote: > > > Perhaps it might be possible to tell tor about > > > the router's nat policy so that if the router is > > > supposed to port forward the external request > > > to :, tor does it itself. > > > That way, the problematic > > > > > > host->tor->tor->your host tor->router->your host > web > > > > > > can become > > > > > > host->tor->tor->your host tor->your host web > > > > > > (This requires some changes to the torrc and tor > > > source, so I'd like to add it to the feature > > > request list in case somebody has free time) > > > > That would be a hidden service. Tor already does > that. > What we are talking about is secure defaults for > exit nodes. No, I think a you may have misunderstood the suggestion, I had to read it twice too. :) Perhaps I can try illustrating this better. To start with we have website W hosted on internal private IP P (192.168.1.2) forwarded to the world by a NATting router with internal IP GW (192.168.1.1) at external IP E. Anyone on the outside can (and are supposed to be able to!) get to web site W by accessing E, not P, with or without tor. 1) Site (W) [P]<--- NAT [E]< Internet (anyone) But with or without tor no-one can actually get to W from the intranet, I, on external IP E since the router intercepts that IP, E, and presents its admin console A on E. So, instead of seeing this: 2) Client [I]--->[E] Router Site (W) [P]<--- Router intranet clients get: 3) Client [I]--->[E] Router Admin Console (A) Now, add an internal tor exit relay on the inside of the firewall trying to legitimately get to W on E (similar to 1): 4) Tor <---Router < Internet(anyone) Tor --->[E] Router Site (W) [P] <---Router Note: they are not trying to illegitimately access W at P, but at legitimate E! Instead they end up more like (3): 5) Tor <--- Router < Internet (anyone) Tor --->[E] Router Admin console (A) The suggested fix instead of simply barring E in the exit policy (since it is a legitimate endpoint,) to spoof E with P internally to tor! 6) Tor <- Router < Internet (anyone) Tor --->[P] Site (W) Yes, this is somewhat similar to a hidden service because we are accessing a web site, W, on the inside of the intranet, but that site is supposed to be accessed from the outside we are simply bypassing the obstructed trip to the internal router hoping to just be NATted and bounced back to P (4). The original scenario (4) which is impossible because of (5) would have done the same thing as (6) just by a different route! Does that make more sense and sound reasonable? -Martin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Security concerns/help me understand tor
Kyle Williams wrote: > On Nov 8, 2007 3:54 PM, Jacob Appelbaum <[EMAIL PROTECTED]> wrote: > >> Kyle Williams wrote: > (This requires some changes to the torrc and tor > source, so I'd like to add it to the feature > request list in case somebody has free time) >>> That would be a hidden service. Tor already does that. >>> What we are talking about is secure defaults for exit nodes. >>> >>> That's a horrible idea. You do NOT want everyone to be able to >> anonymously >>> fuck with your router's admin page. >>> You don't need to redirect that specific request either. It needs to be >>> dropped. If you want to offer up a website, then use the hidden service >>> feature of Tor. >>> >> I agree that you don't want someone to mess with my admin page. I don't >> have an admin page, I have a service. >> >> I think that it's a feature that in your presented case has an >> unintended consequence. It's not as useless as you think. Furthermore, >> it's *not* a hidden service. Hidden services are often slower than any >> other Tor network function. You could *also* use a hidden service if you >> wanted but that's not the same thing. >> >> Something useful you could do with the exit enclave: >> Run a mixmaster server >> Run Tor with the ability to exit to your mixmaster server >> Now all people who can use Tor could use mixmaster, even if mixmaster >> was blocked and without exiting through a node you don't trust. >> >> >> ( Yes, I realize you could possibly exit and use the mixmaster network >> without this setup. And yes I realize that mixmaster is able to be >> observed without worry, I think this setup is useful anyway. ) >> >>> If you want to run a hidden server, such as a web site over a .onion >>> address, then that's fine. >>> If your router is disallowing people to access the admin webpage >> interface >>> from the Internet, that's probably a good thing. >>> But if running a Tor exit node opens up that admin webpage to the rest >> of >>> the Tor network, that's not good. At that point, anyone could >> anonymously >>> try and hack your router. God help you if they do get in, then your >> really >>> in trouble. >> Exit enclaves aren't .onions. They're two different things. They're also >> used differently and with different threat models. Furthermore, one is >> very reliable and the other isn't always so reliable at times. It's also >> a known and documented issue. >> You forgot to address the above comments that you quoted. It has relevance to the next question you did address. >> Do you also think Tor should automatically block access to all RFC 1918 >> address space unless otherwise enabled? Why should Tor be so automatic >> about your specific preferences? >> > > How about you not restrict all the RFC 1918 address spaces in your network, > tell which exit node you run, and let me have some fun playing inside your > network anonymously. > I think that's the case right now. Perhaps you could share some of your finding to help people understand your concerns? Regards, Jacob
Re: Security concerns/help me understand tor
Kyle Williams wrote: > On Nov 8, 2007 4:00 PM, Jefferson Iblis <[EMAIL PROTECTED]> wrote: >> Seems the simplest solution would be to, by default, disallow Tor from >> accessing the local network, including what it discovers to be its >> externally accessible IP. Then anyone who wants to allow local access >> can explicitly turn on whatever they think is appropriate. >> > > Exactly. > There are two issues. One is the concept of exit enclaves and another is privileged authorization based on a specific source ip. Regarding enclaves, an option for operators might be nice. You seem to think that it is very important to disable this type of preferential routing. I disagree. Still an option would allow people to address what you're discussing. Such an option could be: DisallowExitEnclave True This means that servers would operate as they do today and people could address that issue if they care to do so. It makes sense to me that the option would only address the issue of exit enclaves. I'd personally like to see exit enclaving enabled as it is today. With that said... As it stands today, any operator can modify their exit policy if they want to effectively disable exit enclaving. Modification to the exit policy would probably also address the unintended consequences you've voiced concern about. Regarding the second issue of privileged authorization based on source ips, Tor can't solve this problem. It's outside of the scope of the the Tor server itself. Furthermore it's possible that it's *intended* and the method of blocking would draw attention. If you take issue with this, contact the node operators in question. Regards, Jacob
Re: Security concerns/help me understand tor
On Nov 8, 2007 4:00 PM, Jefferson Iblis <[EMAIL PROTECTED]> wrote: > On Nov 8, 2007 11:29 PM, Kyle Williams <[EMAIL PROTECTED]> wrote: > > > > > > If you want to run a hidden server, such as a web site over a .onion > > address, then that's fine. > > If your router is disallowing people to access the admin webpage > interface > > from the Internet, that's probably a good thing. > > But if running a Tor exit node opens up that admin webpage to the rest > of > > the Tor network, that's not good. At that point, anyone could > anonymously > > try and hack your router. God help you if they do get in, then your > really > > in trouble. > > > > There is no point in redirecting that type of request, it needs to be > > rejected. > > Maybe replying with a "bad hacker, not root for you!" webpage would > be > > funny though. > > > > Seems the simplest solution would be to, by default, disallow Tor from > accessing the local network, including what it discovers to be its > externally accessible IP. Then anyone who wants to allow local access > can explicitly turn on whatever they think is appropriate. > Exactly.
Re: Security concerns/help me understand tor
On Nov 8, 2007 3:54 PM, Jacob Appelbaum <[EMAIL PROTECTED]> wrote: > Kyle Williams wrote: > >>> > >>> (This requires some changes to the torrc and tor > >>> source, so I'd like to add it to the feature > >>> request list in case somebody has free time) > > > > That would be a hidden service. Tor already does that. > > What we are talking about is secure defaults for exit nodes. > > > > That's a horrible idea. You do NOT want everyone to be able to > anonymously > > fuck with your router's admin page. > > You don't need to redirect that specific request either. It needs to be > > dropped. If you want to offer up a website, then use the hidden service > > feature of Tor. > > > > I agree that you don't want someone to mess with my admin page. I don't > have an admin page, I have a service. > > I think that it's a feature that in your presented case has an > unintended consequence. It's not as useless as you think. Furthermore, > it's *not* a hidden service. Hidden services are often slower than any > other Tor network function. You could *also* use a hidden service if you > wanted but that's not the same thing. > > Something useful you could do with the exit enclave: > Run a mixmaster server > Run Tor with the ability to exit to your mixmaster server > Now all people who can use Tor could use mixmaster, even if mixmaster > was blocked and without exiting through a node you don't trust. > > > ( Yes, I realize you could possibly exit and use the mixmaster network > without this setup. And yes I realize that mixmaster is able to be > observed without worry, I think this setup is useful anyway. ) > > > > > If you want to run a hidden server, such as a web site over a .onion > > address, then that's fine. > > If your router is disallowing people to access the admin webpage > interface > > from the Internet, that's probably a good thing. > > But if running a Tor exit node opens up that admin webpage to the rest > of > > the Tor network, that's not good. At that point, anyone could > anonymously > > try and hack your router. God help you if they do get in, then your > really > > in trouble. > > Exit enclaves aren't .onions. They're two different things. They're also > used differently and with different threat models. Furthermore, one is > very reliable and the other isn't always so reliable at times. It's also > a known and documented issue. > > Do you also think Tor should automatically block access to all RFC 1918 > address space unless otherwise enabled? Why should Tor be so automatic > about your specific preferences? > How about you not restrict all the RFC 1918 address spaces in your network, tell which exit node you run, and let me have some fun playing inside your network anonymously. > (To be clear, I'm not trying to downplay the usefulness of hidden > services or say that they're implemented poorly. I like them. I use one > on a daily basis for the TorDNSEL.) > > -jake >
Re: Security concerns/help me understand tor
On Nov 8, 2007 11:29 PM, Kyle Williams <[EMAIL PROTECTED]> wrote: > > > If you want to run a hidden server, such as a web site over a .onion > address, then that's fine. > If your router is disallowing people to access the admin webpage interface > from the Internet, that's probably a good thing. > But if running a Tor exit node opens up that admin webpage to the rest of > the Tor network, that's not good. At that point, anyone could anonymously > try and hack your router. God help you if they do get in, then your really > in trouble. > > There is no point in redirecting that type of request, it needs to be > rejected. > Maybe replying with a "bad hacker, not root for you!" webpage would be > funny though. > Seems the simplest solution would be to, by default, disallow Tor from accessing the local network, including what it discovers to be its externally accessible IP. Then anyone who wants to allow local access can explicitly turn on whatever they think is appropriate.
Re: Security concerns/help me understand tor
On Nov 8, 2007 8:53 AM, Martin Fick <[EMAIL PROTECTED]> wrote: > On Wed, Nov 07, 2007 at 08:20:37AM -0800, Martin > Fick wrote: > > My home router offers an http administration > > console on port 80 which for obvious security > > reasons is normally only accessible from the > > internal facing side of the router. While > > many of these home routers typically have an > > internal private IP such as 192.168.1.1 and > > an external public IP, they sometimes respond > > to both IPs from the inside and sometimes they > > even allow access to the administration console > > on the external IP if it is accessed from the > > internal side of the router (mine does). This > > would not normally be a problem, but add a tor > > exit server to the inside of a home network > > serviced by such a router and ...you can > > probably guess where I am going with this. > > ... > --- Kyle Williams <[EMAIL PROTECTED]> wrote: > > > > If anyone is concerned about this, and you should > > be add the following to your torrc. > > > > ExitPolicy reject :* > > > > Obviously replacing with your > > real IP address...not your internal (LAN) IP > address. > > ... > --- Jacob Appelbaum <[EMAIL PROTECTED]> wrote: > > > > I run a few services on the net. I like the idea > > that if I run a Tor server on the same machine > > (on the same interface, with the same IP) as > > my service, people using Tor will prefer my node as > > their exit node. This allows me to provide services > > indirectly to the Tor network without very much > > effort. Smart routing is neato. This is a > > feature and a pretty neat one at that. > > ... > --- Ruben Garcia <[EMAIL PROTECTED]> wrote: > > Perhaps it might be possible to tell tor about the > > router's nat policy so that if the router is > > supposed to port forward the external request > > to :, tor does it itself. > > That way, the problematic > > > > host->tor->tor->your host tor->router->your host web > > > > > can become > > > > host->tor->tor->your host tor->your host web > > > > (This requires some changes to the torrc and tor > > source, so I'd like to add it to the feature > > request list in case somebody has free time) > That would be a hidden service. Tor already does that. What we are talking about is secure defaults for exit nodes. > > This seems like a nice valid option, spoofing > the external IP from within the tor exit node? > In other words if the web internal IP is say: > 192.168.1.2, any request for the external > IP through the tor exit would actually yield > a request directly to the web server's internal > IP, 192.168.1.2, instead? > That's a horrible idea. You do NOT want everyone to be able to anonymously fuck with your router's admin page. You don't need to redirect that specific request either. It needs to be dropped. If you want to offer up a website, then use the hidden service feature of Tor. > That sounds like a nice feature to be able to > get the best of both worlds: 1) security for > the relay operator and 2) for users accessing > the NATed web site! Yes, a hidden service will work behind a router (or NAT'd setup). > > Naturally this should be configurable for > specific ports only. Of course, adding an > IP spoofing mechanism directly to tor exit > nodes makes it that much easier for IPs in > general to be spoofed by exit nodes! :( > > > -Martin > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > If you want to run a hidden server, such as a web site over a .onion address, then that's fine. If your router is disallowing people to access the admin webpage interface from the Internet, that's probably a good thing. But if running a Tor exit node opens up that admin webpage to the rest of the Tor network, that's not good. At that point, anyone could anonymously try and hack your router. God help you if they do get in, then your really in trouble. There is no point in redirecting that type of request, it needs to be rejected. Maybe replying with a "bad hacker, not root for you!" webpage would be funny though. - Kyle
Using Torbutton to toggle between Privoxy+Tor and vanilla Privoxy (was: [privoxy-users] Toggling Privoxy?)
Jim Ford <[EMAIL PROTECTED]> wrote: > I've got Privoxy and Tor installed on a Win XP machine, via the Vidalia > package. I've also got the Firefox Torbutton installed. > > How do I toggle Tor on/off without affecting the status of Privoxy? If I > turn Tor off, via the Torbutton of Vidalia, Privoxy also gets turned off. I don't use Torbutton, but I think it simply changes the browser's proxy settings. While Privoxy can be used independently of Tor, Torbutton only lets you either use a HTTP proxy (+ Tor) or no HTTP proxy at all. With Privoxy 3.0.6 and earlier you have to edit Privoxy's main configuration file to change the forwarding settings and I don't know if Firefox gives its extensions the power to do that. Actually I'm not even sure if the Torbutton developer(s) would want to do that anyway. Privoxy 3.0.7 beta (which is supposed to be released this weekend) can be configured to control forwarding settings with HTTP headers and this makes thinks a lot easier for Torbutton and friends, but (again) using that feature may not be desired by the Tor developers. Of course I can speculate a lot about their motives to do or not do anything, but I rather CC or-talk@ so they can give you a definitive answer (Reply-To set as well). Fabian signature.asc Description: PGP signature
Re: Security concerns/help me understand tor
On Wed, Nov 07, 2007 at 08:20:37AM -0800, Martin Fick wrote: > My home router offers an http administration > console on port 80 which for obvious security > reasons is normally only accessible from the > internal facing side of the router. While > many of these home routers typically have an > internal private IP such as 192.168.1.1 and > an external public IP, they sometimes respond > to both IPs from the inside and sometimes they > even allow access to the administration console > on the external IP if it is accessed from the > internal side of the router (mine does). This > would not normally be a problem, but add a tor > exit server to the inside of a home network > serviced by such a router and ...you can > probably guess where I am going with this. ... --- Kyle Williams <[EMAIL PROTECTED]> wrote: > > If anyone is concerned about this, and you should > be add the following to your torrc. > > ExitPolicy reject :* > > Obviously replacing with your > real IP address...not your internal (LAN) IP address. ... --- Jacob Appelbaum <[EMAIL PROTECTED]> wrote: > > I run a few services on the net. I like the idea > that if I run a Tor server on the same machine > (on the same interface, with the same IP) as > my service, people using Tor will prefer my node as > their exit node. This allows me to provide services > indirectly to the Tor network without very much > effort. Smart routing is neato. This is a > feature and a pretty neat one at that. ... --- Ruben Garcia <[EMAIL PROTECTED]> wrote: > Perhaps it might be possible to tell tor about the > router's nat policy so that if the router is > supposed to port forward the external request > to :, tor does it itself. > That way, the problematic > > host->tor->tor->your host tor->router->your host web > > can become > > host->tor->tor->your host tor->your host web > > (This requires some changes to the torrc and tor > source, so I'd like to add it to the feature > request list in case somebody has free time) This seems like a nice valid option, spoofing the external IP from within the tor exit node? In other words if the web internal IP is say: 192.168.1.2, any request for the external IP through the tor exit would actually yield a request directly to the web server's internal IP, 192.168.1.2, instead? That sounds like a nice feature to be able to get the best of both worlds: 1) security for the relay operator and 2) for users accessing the NATed web site! Naturally this should be configurable for specific ports only. Of course, adding an IP spoofing mechanism directly to tor exit nodes makes it that much easier for IPs in general to be spoofed by exit nodes! :( -Martin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: suspicious log warning messages
On Thu, Nov 08, 2007 at 07:02:53AM -0600, Scott Bennett wrote: > Last night my tor server logged some unexpected messages. I've waited > about twelve hours to see whether any relevant discussion appeared on this > list. Thus far, it hasn't, so I'm posting them here in hopes that someone > will explain what he/she was doing. [...] > Nov 07 19:37:24.205 [warn] Not enough good signatures on networkstatus > consensus > Nov 07 19:37:24.221 [warn] Unable to load consensus directory dowloaded from > server '128.31.0.34:9001' > > No more messages of this sort have appeared since the last one shown above. There's a new v3 directory authority, "ides", run by Mike Perry. Apparently, adding it caused some weird bug to show up in the new certificate download code. See Flyspray bug 546. yrs, -- Nick Mathewson pgpjWKaK2FnEe.pgp Description: PGP signature
it is cant get tor server list
I am using TOR 0.2.0.9 windows in network LAN. it is always can't get any server list. How I do it for normal work ? log is here: 十一月 08 07:21:06.059 [Notice] Tor v0.2.0.9-alpha (r12180). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 2 [workstation]) 十一月 08 07:21:06.059 [Notice] Initialized libevent version 1.3e using method win32. Good. 十一月 08 07:21:06.059 [Notice] Opening Socks listener on 127.0.0.1:9050 十一月 08 07:21:06.089 [Notice] Opening Control listener on 127.0.0.1:9051 十一月 08 07:21:13.831 [Warning] Unable to load consensus directory dowloaded from server '219.152.186.188:9030' -- yon. Liuxyon International Organization http://www.ongod.org Best Service From Us
Re: GETINFO desc/all-recent output from 0.2.0.9 differ from 0.2.0.7
On Nov 3, 2007 2:48 PM, Kasimir Gabert <[EMAIL PROTECTED]> wrote: > > On 11/1/07, Olaf Selke <[EMAIL PROTECTED]> wrote: > > hi folks, > > > > the control port command "GETINFO desc/all-recent" provides only 355 > > routers on v0.2.0.9-alpha. 2199 items are returned as expected after > > downgrading to v0.2.0.7-alpha. Since my 0.2.0.9 bandwidth graph looked > > sane, I don't suppose a general problem with v0.2.0.9. > > > > Output of both versions can be found here: > > http://torstatus.blutmagie.de/GETINFO-desc-all-recent-ouput-0.2.0.7.txt > > http://torstatus.blutmagie.de/GETINFO-desc-all-recent-ouput-0.2.0.9.txt > > > > I didn't check v0.2.0.8-alpha. Is there a known bug regarding this > > issue? A couple of tor network status sites rely on "GETINFO > > desc/all-recent" control port output. > > > > regards, Olaf > > > > Hello, > > This has occurred with my installation of Tor as well > (v0.2.0.9-alpha), however for the network status as opposed to the > descriptors. I restarted Tor (stopping and starting, not a HUP), and > it seemed to correct the problems. > > Kasimir > > -- > Kasimir Gabert > This problem has continued to occur, and looking through the logs it seems to be directly connected with the error in 0.2.0.9 which writes to the log file: Nov 08 05:58:16.430 [notice] I learned some more directory information, but not enough to build a circuit. Nov 08 06:04:37.384 [notice] I learned some more directory information, but not enough to build a circuit. Nov 08 06:04:37.649 [notice] I learned some more directory information, but not enough to build a circuit. Nov 08 06:13:10.643 [notice] I learned some more directory information, but not enough to build a circuit. Nov 08 06:13:14.761 [notice] I learned some more directory information, but not enough to build a circuit. Nov 08 06:13:14.819 [notice] I learned some more directory information, but not enough to build a circuit. Nov 08 06:13:16.770 [notice] I learned some more directory information, but not enough to build a circuit. Nov 08 06:13:21.855 [notice] I learned some more directory information, but not enough to build a circuit. -- Kasimir Gabert
suspicious log warning messages
Last night my tor server logged some unexpected messages. I've waited about twelve hours to see whether any relevant discussion appeared on this list. Thus far, it hasn't, so I'm posting them here in hopes that someone will explain what he/she was doing. Nov 07 17:31:22.181 [warn] Unable to load consensus directory dowloaded from server '86.59.21.38:443' Nov 07 17:33:23.059 [warn] Unable to load consensus directory dowloaded from server '86.59.21.38:443' Nov 07 17:43:32.514 [warn] Consensus includes unrecognized authority 'ides' at 216.224.124.114:9030 (contact Mike Perry ; identity 27B6B5996C426270A5C95488AA5BCEB6BCC86956) Nov 07 17:43:32.515 [warn] 1 unknown, 0 missing key, 1 good, 0 bad, 1 no signature, 2 required Nov 07 17:43:32.516 [warn] Not enough good signatures on networkstatus consensus Nov 07 17:43:32.532 [warn] Unable to load consensus directory dowloaded from server '128.31.0.34:9001' Nov 07 18:14:04.693 [warn] Unable to load consensus directory dowloaded from server '86.59.21.38:443' Nov 07 18:25:14.831 [warn] Consensus includes unrecognized authority 'ides' at 216.224.124.114:9030 (contact Mike Perry ; identity 27B6B5996C426270A5C95488AA5BCEB6BCC86956) Nov 07 18:25:14.831 [warn] 1 unknown, 0 missing key, 1 good, 0 bad, 1 no signature, 2 required Nov 07 18:25:14.832 [warn] Not enough good signatures on networkstatus consensus Nov 07 18:25:14.845 [warn] Unable to load consensus directory dowloaded from server '128.31.0.34:9001' Nov 07 18:27:15.752 [warn] Consensus includes unrecognized authority 'ides' at 216.224.124.114:9030 (contact Mike Perry ; identity 27B6B5996C426270A5C95488AA5BCEB6BCC86956) Nov 07 18:27:15.752 [warn] 1 unknown, 0 missing key, 1 good, 0 bad, 1 no signature, 2 required Nov 07 18:27:15.753 [warn] Not enough good signatures on networkstatus consensus Nov 07 18:27:15.764 [warn] Unable to load consensus directory dowloaded from server '128.31.0.34:9001' Nov 07 18:37:27.649 [warn] Unable to load consensus directory dowloaded from server '86.59.21.38:443' Nov 07 19:07:56.753 [warn] Consensus includes unrecognized authority 'ides' at 216.224.124.114:9030 (contact Mike Perry ; identity 27B6B5996C426270A5C95488AA5BCEB6BCC86956) Nov 07 19:07:56.754 [warn] 1 unknown, 0 missing key, 1 good, 0 bad, 1 no signature, 2 required Nov 07 19:07:56.754 [warn] Not enough good signatures on networkstatus consensus Nov 07 19:07:56.766 [warn] Unable to load consensus directory dowloaded from server '128.31.0.34:9001' Nov 07 19:25:13.710 [warn] Unable to load consensus directory dowloaded from server '86.59.21.38:443' Nov 07 19:27:16.812 [warn] Unable to load consensus directory dowloaded from server '86.59.21.38:443' Nov 07 19:37:24.203 [warn] Consensus includes unrecognized authority 'ides' at 216.224.124.114:9030 (contact Mike Perry ; identity 27B6B5996C426270A5C95488AA5BCEB6BCC86956) Nov 07 19:37:24.204 [warn] 1 unknown, 0 missing key, 1 good, 0 bad, 1 no signature, 2 required Nov 07 19:37:24.205 [warn] Not enough good signatures on networkstatus consensus Nov 07 19:37:24.221 [warn] Unable to load consensus directory dowloaded from server '128.31.0.34:9001' No more messages of this sort have appeared since the last one shown above. 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: Security concerns/help me understand tor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kyle Williams escribió: > On Nov 7, 2007 8:52 AM, Roger Dingledine <[EMAIL PROTECTED]> wrote: > >> On Wed, Nov 07, 2007 at 08:20:37AM -0800, Martin Fick wrote: >>> My home router offers an http administration console >>> on port 80 which for obvious security reasons is >>> normally only accessible from the internal facing side >>> of the router. While many of these home routers >>> typically have an internal private IP such as >>> 192.168.1.1 and an external public IP, they sometimes >>> respond to both IPs from the inside and sometimes they >>> even allow access to the administration console on the >>> external IP if it is accessed from the internal side >>> of the router (mine does). This would not normally be >>> a problem, but add a tor exit server to the inside of >>> a home network serviced by such a router and ...you >>> can probably guess where I am going with this. >> Yep. That's why Tor has a notion of exit policies: >> http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#RunARelayBut >> If you really want to restrict connections to sensitive local resources, >> you should reject connections to them in your exit policy. >> >> The default exit policy rejects internal addresses like 10.*, 192.168.*, >> etc, but as you say there may be other sensitive resources depending on >> your situation. >> >> The other half of the answer is that you shouldn't be relying on network >> location for authorization. You should, for example, use a password. >> >> The third half of the answer is that running a web browser and interacting >> with strange websites creates an excellent opportunity already for dns >> rebinding attacks, cross-site foo attacks, etc. See for example the >> "drive-by pharming" report from some folks I've been working with at IU, >> summarized by Bruce Schneier here: >> http://www.schneier.com/blog/archives/2007/02/driveby_pharmin.html >> It's pretty darn scary what bad guys can do to access local resources >> by tricking your browser. >> >> In short, you'd better think harder if you want to both a) run complex >> programs that can act as proxies, such as a web browser and such as Tor, >> and b) do any sort of trust-by-network-location. >> >>> This, of course, should only happen if Alice's tor >>> client chooses Bob's tor server as the exit node. >>> But, if I understand the tor documentation correctly, >>> this would in fact be the preferred way for tor >>> client's to access Bob's website since they should be >>> able to detect that Bob's website and his tor exit >>> server are in fact both (NATed to) the same public >>> IP >> Yes. If you're visiting Bob's website, Tor can provide end-to-end >> authentication and end-to-end encryption without the need for SSL. >> This is a great potential feature. But you're right, Bob had better not >> allow additional access to sensitive resources for people connecting >> from his Tor relay. >> >>> If I am correct about this possibility, and without >>> arguing the virtues of whether these routers are doing >>> the right thing by providing access to the admin >>> console from the external IP from their inward facing >>> interface, I think that tor relay providers should be >>> strongly warned about this possibility in the tor >>> documentation! I am not sure that there is a good >>> default (out of the box) way to prevent this from >>> happening with tor, but I suspect that if Bob sets an >>> exit policy explicitly rejecting his own IP that he >>> would be safe from this sort of compromise? >> Yes, except in cases where a) he doesn't know the extent to which local >> services trust his IP address, and b) he is on a dynamic IP address. >> Unfortunately, I suspect these are exactly the contexts where it's most >> important for users to understand what's going on, *and* exactly the >> contexts where the users will be most ignorant about the issues. >> >> Where do you suggest we put the warnings, and can you suggest some >> sample phrasings? >> >> We could e.g. add a note to step 9 on >> https://www.torproject.org/docs/tor-doc-relay#after >> but I fear that most users can't (won't) count to 9. >> >> Another option is to assume that most home users will be configuring >> relaying via Vidalia, so we should concentrate on explaining all the >> various issues there. (In fact, Vidalia doesn't currently have a good >> interface for letting people tweak their exit policy by *addresses* >> as well as ports.) >> >> Another thought is that Tor relays already know their public IP address, >> since after all they have to advertise it. Perhaps the default exit >> policy should reject connections to that IP address, unless the operator >> explicitly allows them? See also the "ExitPolicyRejectPrivate" entry >> in the man page. This would be a shame to set up by default, but maybe >> secure-by-default-for-end-users is a trend we should embrace. >> >> And lastly, just to cover all bases: is there any point to this additi
Re: Security concerns/help me understand tor
Kyle Williams wrote: > I don't want to post all the results of my research, for fear that truly > evil Torrorist would go crazy with this. Let's just say that this could be > very, very bad. Trust me, Roger, this isn't something that should be taken > lightly. The moment Tor knows it's own external IP, and is operating as an > exit node, it should (in code) automatically disallow connections to it's > own external IP. Unless someone has a really good reason why you would need > access to your external IP address from inside your LAN. > I run a few services on the net. I like the idea that if I run a Tor server on the same machine (on the same interface, with the same IP) as my service, people using Tor will prefer my node as their exit node. This allows me to provide services indirectly to the Tor network without very much effort. Smart routing is neato. This is a feature and a pretty neat one at that. > BTW, I tried the 'responsible discloser' once already in IRC, remember > Roger? > So I don't feel bad one bit for talking about this with others. > At least I included a temporary solution to the problem. > I didn't know about your IRC discussion however, I think you should disclose the results of your research to [EMAIL PROTECTED] I'm sure it would be appreciated and everyone would be keen to hear more about it. Regards, jacob
