Re: Yet another UDP / DNS quiestion...
Yes if you redirect DNS requests to Tor's DNSPort you should be safe against DNS leaks. Do I have to use AutomapHostsOnResolve 1 as well? Seems to be pointless without defining AutomapHostsSuffixes. I guess you are talking about a local setup without a middlebox involved. If my assumption is correct you want to refer to the following section in the document: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy#LocalRedirectionThroughTor Thanks for clarifying that! Now I need to read some more about iptables. One more question: will those rules route all UDP traffic to port 53 or just DNS requests? What will happen with UDP not relating to DNS? -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Re: Yet another UDP / DNS quiestion...
On 02/13/2011 03:20 PM, Tomasz Moskal wrote: Do I have to use AutomapHostsOnResolve 1 as well? Seems to be pointless without defining AutomapHostsSuffixes. No it is not pointless because also if you do not use AutomapHostsSuffixes in your config .exit and .onion are AutomapHostsSuffixes per default. One more question: will those rules route all UDP traffic to port 53 or just DNS requests? What will happen with UDP not relating to DNS? The UDP rules in the LocalRedirectionThroughTor section: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy#LocalRedirectionThroughTor redirect only UDP packets with destination port 53 (usually DNS requests) to the DNSPort. All other outgoing UDP traffic is blocked/rejected with the last rule: iptables -A OUTPUT -j REJECT The penultimate rule: iptables -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT would allow a program running with the $TOR_UID to send UDP traffic. I will suggest to add -p tcp to that rule. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Excluding exit nodes
From the Tor Project FAQ https://www.torproject.org/docs/faq#ChooseEntryExit: We recommend you do not use these — they are intended for testing and may disappear in future versions. You get the best security that Tor can provide when you leave the route selection to Tor; overriding the entry / exit nodes can mess up your anonymity in ways we don't understand. Now, it's a little bit confusing for a novice, let me explain why. People both on this mailing list and else where on the Internet are often referring to excluding bad/evil exit nodes (I'm aware that it's a bit ambiguous concept) and yet there is this entry in Tor Project FAQ. So how someone like me, a newcomer to Tor, Linux and networking, should know which exit nodes are suspicious? I came across this website http://torstatus.blutmagie.de/index.php which flags couple of nodes as Bad Exit - should I exclude them? How reliable information on this website are? Is there any authoritative list of suspicious exit nodes? -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Re: Excluding exit nodes
On 02/13/2011 03:43 PM, Tomasz Moskal wrote: Now, it's a little bit confusing for a novice, let me explain why. People both on this mailing list and else where on the Internet are often referring to excluding bad/evil exit nodes (I'm aware that it's a bit ambiguous concept) and yet there is this entry in Tor Project FAQ. The config directive ChooseEntryExit should not be confused with ExcludeExitNodes. So how someone like me, a newcomer to Tor, Linux and networking, should know which exit nodes are suspicious? I came across this website http://torstatus.blutmagie.de/index.php which flags couple of nodes as Bad Exit - should I exclude them? No you do not need to exclude them because your client will not use nodes with the BadExit flag as an exit node anyway. The torstatus website does not flag them, it just shows you that they have this flag because the DirectoryAuthorities flagged these nodes as badexits. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Excluding exit nodes
On Sun, 2011-02-13 at 15:51 +0100, tagnaq wrote: No you do not need to exclude them because your client will not use nodes with the BadExit flag as an exit node anyway. The torstatus website does not flag them, it just shows you that they have this flag because the DirectoryAuthorities flagged these nodes as badexits. Now I'm even more confused! What is DirectoryAuthorities? Quick googling yielded no results I can understand and Tor -alpha Manual is not helpful on that matter either. Could you point me somewhere I can find more informations about matters relating to exit nodes? I'm going through archives of this mailing list and documents on Tor website but there is *a lot* of informations in those places and it will take me considerable amount of time to read all of it. How someone can recognise if an exit node *might* be doing something suspicious - like sniffing traffic for passwords? As far as I can tell (with my limited knowledge that is!) it's by checking which ports the node in question is making available. And if there are not the standards one then it *could* do something nasty - which of course don't mean it does. Could you clarify this whole rouge/bad/evil nodes matter? -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Re: Excluding exit nodes
On 02/13/2011 04:19 PM, Tomasz Moskal wrote: Now I'm even more confused! What is DirectoryAuthorities? Could you point me somewhere I can find more informations about matters relating to exit nodes? https://www.torproject.org/docs/faq.html.en#KeyManagement (Coordination section) General Design Document: https://www.torproject.org/docs/documentation.html.en#DesignDoc https://svn.torproject.org/svn/projects/design-paper/tor-design.html (chapter 6.3) Note: This document is from 2004. Statements like new nodes must be approved by the directory server administrator before they are included are no longer valid. https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/dir-spec.txt#l142 How someone can recognise if an exit node *might* be doing something suspicious - like sniffing traffic for passwords? As far as I can tell (with my limited knowledge that is!) it's by checking which ports the node in question is making available. And if there are not the standards one then it *could* do something nasty - which of course don't mean it does. Could you clarify this whole rouge/bad/evil nodes matter? Well this is currently a 'hot topic' and I refer you to the lengthy thread 'Is gatereloaded a Bad Exit?'. Short answer: you can not reliably detect passive sniffing. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Excluding exit nodes
On Sun, 2011-02-13 at 17:07 +0100, tagnaq wrote: https://www.torproject.org/docs/faq.html.en#KeyManagement (Coordination section) General Design Document: https://www.torproject.org/docs/documentation.html.en#DesignDoc https://svn.torproject.org/svn/projects/design-paper/tor-design.html (chapter 6.3) Note: This document is from 2004. Statements like new nodes must be approved by the directory server administrator before they are included are no longer valid. https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/dir-spec.txt#l142 Wow! This will keep me busy for quite a while! Thanks! Well this is currently a 'hot topic' and I refer you to the lengthy thread 'Is gatereloaded a Bad Exit?'. Short answer: you can not reliably detect passive sniffing. Yes, I'm following 'Is gatereloaded a Bad Exit?' but at times it's *very* confusing. Well, I won't worry about exit nodes until I won't have better understanding of Tor and networking in general. -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Re: Excluding exit nodes
On 2/13/2011 10:19 AM, Tomasz Moskal wrote: [snip] How someone can recognise if an exit node *might* be doing something suspicious - like sniffing traffic for passwords? As far as I can tell (with my limited knowledge that is!) it's by checking which ports the node in question is making available. And if there are not the standards one then it *could* do something nasty - which of course don't mean it does. Could you clarify this whole rouge/bad/evil nodes matter I think it's worth mentioning that as an end-user you might be focusing on the wrong issues here. While there *may* be some nodes (exactly which is perpetually unknown) that record unencrypted traffic, it's more important to make sure that your private data (such as login credentials, text containing your whereabouts, etc) is encrypted end-to-end than to worry about excluding every possibly bad exit node. For example, it's much easier to use the https version of a website instead of http to protect a username/password combination than it would be to hunt down anyone who might be trying to record your http connection (as recording the encrypted https traffic would yield them nothing). The same logic applies to other tools as well, examples being using the encrypted ssh and sftp over telnet and ftp, respectively. See https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#CanexitnodeseavesdroponcommunicationsIsntthatbad if you haven't already. To answer your other question, as I understand it, the traditional definition of bad exit nodes has been ones that manipulate (actually change, rather than simply record) data as they pass through the node. These nodes are automatically awarded the BadExit flag and are not used as exits, so the end-user need not worry about them. Exactly whether using an asinine exit polixy should cause a node to be considered malicious has been a point of argument over the last week or so here, and relates only to the sniffing of unencrypted traffic. So again, make sure to use encrypted protocols wherever possible, and don't send any personally-identifiable information when forced to use unencrypted protocols, and you should be fine. Others will be better able to answer the other questions you had. Good luck, and stay safe! ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Excluding exit nodes
On Sun, Feb 13, 2011 at 11:39 AM, Tomasz Moskal ramshackle.industr...@gmail.com wrote: [snip] Would you recommend using not Tor connection when one is forced to use unencrypted protocols? I think I'm safer using Tor even with unencrypted traffic that using regular connection but again I can be gravely wrong here. What do you think? This depends on the network near you and what risks you're worried about being safe from. If you're concerned about anonymity then sure, tor should pretty much always be safer. (Though will you have anonymity when you're logging in? It depends…) As for security against eavesdropping— I think you can say that tor is more secure in that regard than a network where you _know_ it's happening, and less secure against that than most networks where you are unsure. In some cases, however, even if eavesdropping is happening it's better if the eavesdropper is someone socially/geographically far away. I might be more happy about someone in japan, who mostly just wants my passwords, reading my private messages than the sysadmin at the local ISP who knows some of my friends personally. Eavesdropping is also usually far less damaging if the traffic has been successfully anonymized. Really, it comes down to this: If you do not use end to end encryption your traffic can be monitored or manipulated by a great many people— by hackers with access to the network between you and the other end, by the staff of network providers, potentially by commercial agencies that ISPs have sold feeds of customer data to, by governments along the path, etc. This is true regardless of Tor. If you use Tor than the people who can do these things are changed (e.g. some other ISP instead of yours) and possibly increased (the exit operator might be doing something nasty). What Tor provides is the aspects of privacy that encryption can't get you, but it doesn't replace end to end encryption. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Yet another UDP / DNS quiestion...
On 02/13/2011 05:21 PM, Tomasz Moskal wrote: OK, so to wrap it all up last (hopefully!) couple of questions... iptables script/rules set: #!/bin/sh # the UID Tor runs as TOR_UID=109 iptables -F iptables -t nat -F # Redirects DNS traffic to the local port 53 iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53 # Allow a program running with the $TOR_UID to send UDP traffic iptables -A OUTPUT -p udp -m owner --uid-owner $TOR_UID -j ACCEPT Why did you add -p udp here? Tor uses TCP. # Block/reject all outgoing UDP traffic iptables -A OUTPUT -j REJECT This rule does not block UDP only, it rejects all traffic including UDP (if a packets makes its way to the last line). If this is your full iptables setup it doesn't make much sense to me. You might have misunderstood my earlier reply. But lets go one step back: I'm wondering why one would want to setup DNSPort configuration without TransPort. I see two obvious use cases but neither matches yours: scenario 1) firefox+polipo+torbutton enabled in such a setup there is no need for DNSPort + iptables if you are only worried about firefox traffic scenario 2) you want to route all TCP traffic through Tor: setup includes TransPort + DNSPort Setup (to prevent DNS leaking) + iptables rules + Torbutton (transparent torification setting) Could you describe your use case + thread model? On my machine Tor seems to have different UID after each restart (at least this is what ps -A | grep -w tor tells me). How I can force it to use always the same UID? According to this thread http://ubuntuforums.org/showthread.php?t=800066a I can't change it when Tor is already running so my guess is I should force it to use chosen UID before it will even start. I wonder why your uid should be different everytime you reboot, but you can also use the name of the user instead of the numerical value. I couldn't find (man iptables) nothing about -m owner - should I replace owner with my login or it is to match Tor through --uid-owner $TOR_UID? The word 'owner' after -m is _not_ a variable that needs to be replaced. It is the match extension module name. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Yet another UDP / DNS quiestion...
Could you describe your use case + thread model? I'm terrible sorry for chaos I'm causing but right now I'm a very small and confused person :-) Let me start from the beginning... I'm using Privoxy + Tor combination. For Privoxy to properly handle TCP/HTTP requests and send them over Tor network I have listen-address 127.0.0.1:8118 in my /etc/privoxy/config. Then, to make sure that Privoxy will be used globally, I added those four lines to /etc/environment: http_proxy=http://127.0.0.1:8118/; https_proxy=https://127.0.0.1:8118/; HTTP_PROXY=$http_proxy HTTPS_PROXY=$https_proxy Now all TCP/HTTP traffic should go through Privoxy - Tor combination, at least in theory. As I understand Wireshark is the tool I should use to verify if that is what is happening in reality. I compiled Wireshark but don't understand yet how to use it so I will come back to verify routing of TCP/HTTP when I understand what I'm doing. Next, I tried to use torsocks to make sure UDP/DNS requests are resolved through Tor. To accomplish that I added to /etc/privoxy/config forward-socks4a / 127.0.0.1:9050 . forward-socks5 /127.0.0.1:9050 . My /etc/torsocks.conf looks like this: local = 127.0.0.0/255.128.0.0 local = 127.128.0.0/255.192.0.0 local = 169.254.0.0/255.255.0.0 local = 172.16.0.0/255.240.0.0 local = 192.168.0.0/255.255.0.0 server = 127.0.0.1 server_port = 9050 But I have two problems with using torsocks: 1. Not all applications seems to be working with it, for example when I try usewithtor empathy I'm getting Segmentation fault. Which is probably due to the problems with rejecting UDP: torsocks allows you to use most socks-friendly applications in a safe way with Tor. It ensures that DNS requests are handled safely and explicitly rejects UDP traffic from the application you're using. (from https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorifyHOWTO) 2. I would need to usewithtor every single application on my system to make sure DNS requests are resolved through Tor. Then I came around Transparently Routing Traffic Through Tor https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy. And this is where more confusion and problems started! What I want to achieve with this wiki is to make sure all UDP/DNS request will be send through Tor. Now I intend to follow Local Redirection Through Tor from mentioned wiki to the letter and that will hopefully resolve the case of leaking DNS. # Block/reject all outgoing UDP traffic iptables -A OUTPUT -j REJECT This rule does not block UDP only, it rejects all traffic including UDP (if a packets makes its way to the last line). So if I will go ahead with set-up from Local Redirection Through Tor it will allow out just the traffic going through Tor stopping any and every kind of no-Tor traffic from leaving my machine. But if I want to allow traffic from certain applications I could do it by setting up exception in iptables, right? And furthermore, with this solution there will be no need for me to use torsocks any more, yes? iptables -A OUTPUT -p udp -m owner --uid-owner $TOR_UID -j ACCEPT Why did you add -p udp here? Tor uses TCP. My mistake! Fixed now. I'm wondering why one would want to setup DNSPort configuration without TransPort. That will be lack of knowledge on my part, I missunderstood informations from wiki. I got confused by this comment http://www.hermann-uwe.de/blog/howto-anonymous-communication-with-tor-some-hints-and-some-pitfalls#comment-80205 which doesn't mention TransPort and thus I thought it is not necessary. I wonder why your uid should be different everytime you reboot, but you can also use the name of the user instead of the numerical value. Well I can't tell you why but that how it is. To double check I rebooted twice just now and ps -A | grep -w tor each time gave me different UID for tor. -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Re: Yet another UDP / DNS quiestion...
On Sun, 13 Feb 2011 18:50:19 + Tomasz Moskal ramshackle.industr...@gmail.com wrote: I wonder why your uid should be different everytime you reboot, but you can also use the name of the user instead of the numerical value. Well I can't tell you why but that how it is. To double check I rebooted twice just now and ps -A | grep -w tor each time gave me different UID for tor. That's a process ID, not a user ID. Robert Ransom signature.asc Description: PGP signature
Scroogle and Tor
I've been fighting two different Tor users for a week. Each is apparently having a good time trying to see how quickly they can get results from Scroogle searches via Tor exit nodes. The fastest I've seen is about two per second. Since Tor users are only two percent of all Scroogle searches, I'm not adverse to blocking all Tor exits for a while when all else fails. These two Tor users were rotating their search terms, and one also switched his user-agent once. You can see why I might be tempted to throw my block all Tor switch on occasion -- sometimes there's no other way to convince the bad guy that he's not going to succeed. When a nonprofit such as the Tor Project or Scroogle offers a public service, the script kiddies should have more respect. I don't expect everyone to donate to Tor and Scroogle, but I do expect that no one will steal time and effort from us. By the way, my block all Tor options for my Scroogle servers use an expanded definition of which IPs are Tor exit nodes. I pull the blutmagie.de exit node list, or the torproject.org exit node list (both port 80 and port 443) once per half hour, alternating between the two sites. One custom switch I use is a cumulative list from yesterday and today, all in one list with duplicates purged. The other switch I created is a moving cumulative list from today plus the previous six days. Why do I do this? Well, Tor's DNSEL using dig is too much overhead, compared to searching a sorted list on my servers. But the available exit node lists from the Tor directory are strange, to say the least. The list size from blutmagie.de can be as much as several hundred IPs different than the list from torproject.org, even within the same one-hour period. Moreover, they are extremely dynamic. While the current list is usually around 1100 IPs, the cumulative list from yesterday plus today is usually about 2600 unique IPs. The list from today plus the six previous days is anywhere from 4500 to 7500 unique IPs. I've been watching these numbers for over a year now -- take my word for it that what I'm describing is a consistent pattern, not some momentary fluke. I'm getting to the point where I'm tempted to offer my two exit node lists (yesterday plus today, and previous six days plus today) to the public. If I had more confidence in the lists currently available to the public, I wouldn't be tempted to do this. -- Daniel Brandt *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Yet another UDP / DNS quiestion...
On Sun, 2011-02-13 at 11:04 -0800, Robert Ransom wrote: That's a process ID, not a user ID. Arrrgh! My brain is slowly melting. I think what I will do now is to give up on Tor and attempts to understand it. I will explore more how to properly and effectively use Linux. Then I shall delve some more into basic concepts behind Internet Protocols and THEN, just then, I will come back to Tor. Well, see you folks in a year or two! -- Tomasz Moskal ramshackle.industr...@gmail.com Encrypted mail preferred. Key ID: 2C323C82 signature.asc Description: This is a digitally signed message part
Re: Scroogle and Tor
On Sun, Feb 13, 2011 at 2:09 PM, scroo...@lavabit.com wrote: [snip] I'm getting to the point where I'm tempted to offer my two exit node lists (yesterday plus today, and previous six days plus today) to the public. If I had more confidence in the lists currently available to the public, I wouldn't be tempted to do this. You should. The current public exit service is demonstrably incorrect. Although it's also important to know why it's incorrect. For example, one reason that the DNSEL is incorrect is a side effect of that fact that they are tested to see what address they _really_ exit from. Sometimes an exit is placed behind some proxy and the address that it claims to be is not the address anyone else sees. But— if an exit has a policy so narrow that it can not be tested by this process then it will not show up in the DNSEL results. So, e.g. if I ran a scroogle only exit, it wouldn't be in the DNSEL results. I'm pretty sure this is the wrong failure mode for the testing process. Though this issue means that your non-testing based results will also be incorrect, just in another way. There may also be other issues with the DNSEL result which I am unaware of. The daily/weekly cycle part just sounds like the pattern of nodes hitting their transfer limits and shutting off. Perhaps the DNSEL is promptly delisting these nodes when there should be a hold-up because the DNSEL results are cached. As far as performance goes, you can download a list of nodes which can reach a particular address at https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.2.3.4 but, these results have the same problem with omitted nodes that I mentioned. As far as the annoying requests from tor goes, it would be better to subject them to a captcha than to block them completely. Then again, the big reason people use scroogle via tor is, as I understand it, to avoid the annoying captchas that google often subjects tor exits to... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Sent e-mails going into spam folders.
Am 13.02.2011 00:54, schrieb Matthew: Incidentally, in http://torstatus.blutmagie.de/ gpfTOR4 is listed as being in the Czech Republic while gpfTOR5 and gpfTOR6 are in Netherlands. Is this correct? Yes, coorect. In the last years we see much less trouble by using non-German ISPs for our Tor nodes. gpfTOR4 is hosted by coolhousing.net, gpfTOR5 and gpfTOR6 are hosted by leaseweb.nl. Greetings Karsten N. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scroogle and Tor
On 13/02/11 19:09, scroo...@lavabit.com wrote: I've been fighting two different Tor users for a week. Each is apparently having a good time trying to see how quickly they can get results from Scroogle searches via Tor exit nodes. The fastest I've seen is about two per second. Since Tor users are only two percent of all Scroogle searches, I'm not adverse to blocking all Tor exits for a while when all else fails. These two Tor users were rotating their search terms, and one also switched his user-agent once. You can see why I might be tempted to throw my block all Tor switch on occasion -- sometimes there's no other way to convince the bad guy that he's not going to succeed. For the less than knowledgeable people amongst us (e.g me) who want to learn a bit more: what was the rationale for those two Tor users doing what they did? What do they get from it? Incidentally, I use the SSL version of Scroogle (sometimes with Tor, sometimes without) because a) no CAPTCHAs b) I appreciate your privacy-minded ethos (ideology). It would be a shame if you had to block Tor users because of an abusive minority. When a nonprofit such as the Tor Project or Scroogle offers a public service, the script kiddies should have more respect. I don't expect everyone to donate to Tor and Scroogle, but I do expect that no one will steal time and effort from us. By the way, my block all Tor options for my Scroogle servers use an expanded definition of which IPs are Tor exit nodes. I pull the blutmagie.de exit node list, or the torproject.org exit node list (both port 80 and port 443) once per half hour, alternating between the two sites. One custom switch I use is a cumulative list from yesterday and today, all in one list with duplicates purged. The other switch I created is a moving cumulative list from today plus the previous six days. Why do I do this? Well, Tor's DNSEL using dig is too much overhead, compared to searching a sorted list on my servers. But the available exit node lists from the Tor directory are strange, to say the least. The list size from blutmagie.de can be as much as several hundred IPs different than the list from torproject.org, even within the same one-hour period. Moreover, they are extremely dynamic. While the current list is usually around 1100 IPs, the cumulative list from yesterday plus today is usually about 2600 unique IPs. The list from today plus the six previous days is anywhere from 4500 to 7500 unique IPs. I've been watching these numbers for over a year now -- take my word for it that what I'm describing is a consistent pattern, not some momentary fluke. I'm getting to the point where I'm tempted to offer my two exit node lists (yesterday plus today, and previous six days plus today) to the public. If I had more confidence in the lists currently available to the public, I wouldn't be tempted to do this. -- Daniel Brandt *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Sent e-mails going into spam folders.
On 13/02/11 21:03, Karsten N. wrote: Am 13.02.2011 00:54, schrieb Matthew: Incidentally, in http://torstatus.blutmagie.de/ gpfTOR4 is listed as being in the Czech Republic while gpfTOR5 and gpfTOR6 are in Netherlands. Is this correct? Yes, coorect. In the last years we see much less trouble by using non-German ISPs for our Tor nodes. gpfTOR4 is hosted by coolhousing.net, gpfTOR5 and gpfTOR6 are hosted by leaseweb.nl. Could you please say a little more about what the trouble in Germany was and why Dutch and Czech exit nodes involve less trouble? Thanks. Greetings Karsten N. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scroogle and Tor
Gregory Maxwell wrote: As far as performance goes, you can download a list of nodes which can reach a particular address at https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.2.3.4 but, these results have the same problem with omitted nodes that I mentioned. That's the torproject.org bulk list I've been using, alternating with the blutmagie.de list. When I download the torproject.org list I ask for exit nodes that can reach one of my servers. I alternate between asking for port 443 and port 80 on that server. Someone else emailed me directly: Seems like you could get a lot smarter about this and block successive queries from the same IP that happen less than a few seconds from each other. Difficult, because blutmagie.de and another high-traffic site account for about 20 percent of my total Tor requests. I have to exempt them from some of my screening if there's a chance of false positives. I'm already doing something like what you suggest, after exempting these two sites. It's normally turned off, but I try this first when I have a problem. I try other things too before blocking all exit nodes. Another problem is that search-engine use presents a special challenge. Often legitimate searchers fire off a few searches in quick succession. The input box is right there, and they may modify it just slightly and fire off another search. An extreme example of this is something I see several times a week outside of Tor (which is too slow to do this). Someone has a Scroogle search plugin out there that mimics an instant-search feature for every keystroke as you key in your search term. This is something Google introduced last year. But trying to do this on Scroogle is insane. Even if it works to the user's satisfaction, I consider this extremely abusive, and I block these IPs for a week as soon as I see it happening. The reason it's insane is that Scroogle has six servers, while Google has several hundred thousand servers. I wish these script kiddies would do the math first! -- Daniel Brandt *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scroogle and Tor
On Sun, 13 Feb 2011 14:09:56 -0500 (EST) scroo...@lavabit.com wrote: I've been fighting two different Tor users for a week. Each is apparently having a good time trying to see how quickly they can get results from Scroogle searches via Tor exit nodes. I've talked to a few services that do one of the following: - Run a Tor exit enclave, which would only allow exit through Tor to your webservers. There are a few services that run a tor client and simply block every IP in the consensus, except their exit enclave. - Run a hidden service. Due to the current state of hidden services, it'll slow down everything. - Run a tor exit enclave against one, non-load balanced server for tor users. If someone abuses it, the reality of slower response times is a self-enforcing feedback loop. Of course, this sucks for the non-abusers. - Rate limiting queries in the application. The Google solution of CAPTCHA. The Yahoo/Bing solution of throwing up a temporary error page when queries cross some threshold per IP address. -- Andrew pgp 0x74ED336B *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: or-talk list migration Feb 19, 2011
A reminder that this migration occurs this week. On Mon, 24 Jan 2011 15:05:03 -0500 Andrew Lewman and...@torproject.org wrote: Hello or-talk subscribers, On February 19, 2011, we are migrating or-talk from or-t...@seul.org to tor-t...@lists.torproject.org. We will migrate your e-mail address's subscription to the new list. You will receive a confirmation from the new mailing list software on the 19th. Current or-talk archives will be migrated. Roger plans to leave the current archives in place at seul.org as well. We're using this migration to spread administration out to Tor's sysadmin team rather than making Roger do everything himself. The secondary benefits of having the lists on the torproject.org domain include SSL-enabled login, archives, and easier account management. You can subscribe to the new list at https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk I will send out a reminder on the day of the migration. Please e-mail tor-assista...@torproject.org with any questions. Thank you. -- Andrew pgp 0x74ED336B *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scroogle and Tor
On Sun, Feb 13, 2011 at 9:34 PM, Andrew Lewman and...@torproject.org wrote: I've talked to a few services that do one of the following: - Run a Tor exit enclave, which would only allow exit through Tor to your webservers. There are a few services that run a tor client and simply block every IP in the consensus, except their exit enclave. [snip] This one can be kind of lame, because some requests to an enclaved host (in particular, the first one always) will hit some random exit. Depending how you do the blocking this can give unexpected results. It would be nice if there were some roadmap to fixing this, since it really diminishes the usefulness of enclaves as a mechanism for reducing problems due to misbehaving exits. Likewise, the extra hop probably washes out a lot of the benefit of an enclave as a performance enhancement (though not as much as a hidden service). It can also be tricky to run an enclave when you DNS load-balancing (especially with multiple datacenters): You must have an 'apparent' Tor node on every IP that your DNS returns. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
