Blocked from yelp.com?
Hi, I am forbidden to access the server yelp.com. Is that because I am a Tor exit node? Thanks David 0xDC7C8BF3.asc Description: application/pgp-keys
Is gatereloaded a Bad Exit?
Hi, while scrolling through the tor status page (torstatus.blutmagie.de), I stumpled upon the following node (the reason why it came to my eye was the long uptime): gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92 This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* reject 194.154.227.109:* accept *:21 accept *:80 accept *:110 accept *:143 reject *:* Am I missing something? I'm wondering why the status page lists this node as non-exit, because it clearly allows outgoing traffic on ports 21,80,110 and 143? I'm aware of the fact that it is not recommended to use tor without additional encryption, but some users do. And I dont see any reason for only allowing unencrypted traffic than snooping? Can anyone clearify this? If the admin of this node is on the list, would he please explain this situation? best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Sat, Jan 29, 2011 at 12:46 PM, Jan Weiher j...@buksy.de wrote: Hi, while scrolling through the tor status page (torstatus.blutmagie.de), I stumpled upon the following node (the reason why it came to my eye was the long uptime): gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92 This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* reject 194.154.227.109:* accept *:21 accept *:80 accept *:110 accept *:143 reject *:* Am I missing something? I'm wondering why the status page lists this node as non-exit, because it clearly allows outgoing traffic on ports 21,80,110 and 143? I'm aware of the fact that it is not recommended to use tor without additional encryption, but some users do. And I dont see any reason for only allowing unencrypted traffic than snooping? Can anyone clearify this? If the admin of this node is on the list, would he please explain this situation? best regards, Jan It may possible be a middle node instead of an exit node. As for lack of contact info, can't answer that. I know there have been several other nodes in past without a contact info. Jon *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
Am 29.01.2011 20:13, schrieb Jon: On Sat, Jan 29, 2011 at 12:46 PM, Jan Weiher j...@buksy.de wrote: Hi, while scrolling through the tor status page (torstatus.blutmagie.de), I stumpled upon the following node (the reason why it came to my eye was the long uptime): gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92 This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* reject 194.154.227.109:* accept *:21 accept *:80 accept *:110 accept *:143 reject *:* Am I missing something? I'm wondering why the status page lists this node as non-exit, because it clearly allows outgoing traffic on ports 21,80,110 and 143? I'm aware of the fact that it is not recommended to use tor without additional encryption, but some users do. And I dont see any reason for only allowing unencrypted traffic than snooping? Can anyone clearify this? If the admin of this node is on the list, would he please explain this situation? best regards, Jan It may possible be a middle node instead of an exit node. As far as I understand the ExitPolicy, the first matching rule applies. Which means, that this is an Exit Node, at least for ports 21,80,110 and 143 to IP adresses that do not match the reject rules above the corresponding accept rules. Anyone is free to correct me if I'm wrong, but a middle node has only _one_ ExitPolicy which is reject *:*. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On 2011-01-29 19:46, Jan Weiher wrote: while scrolling through the tor status page (torstatus.blutmagie.de), I stumpled upon the following node (the reason why it came to my eye was the long uptime): gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92 This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* reject 194.154.227.109:* accept *:21 accept *:80 accept *:110 accept *:143 reject *:* Am I missing something? I'm wondering why the status page lists this node as non-exit, because it clearly allows outgoing traffic on ports 21,80,110 and 143? See: 'https://gitweb.torproject.org/arma/tor.git/blob_plain/03b9c2cb903cc59f83139039d963f1fdea99b83a:/doc/spec/dir-spec.txt' Exit -- A router is called an 'Exit' iff it allows exits to at least two of the ports 80, 443, and 6667 and allows exits to at least one /8 address space. Also: http://www.mail-archive.com/or-talk@freehaven.net/msg10275.html *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
Am 29.01.2011 21:27, schrieb Gitano: On 2011-01-29 19:46, Jan Weiher wrote: while scrolling through the tor status page (torstatus.blutmagie.de), I stumpled upon the following node (the reason why it came to my eye was the long uptime): gatereloaded 550C C972 4FA7 7C7F 9260 B939 89D2 2A70 654D 3B92 This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:* reject 194.154.227.109:* accept *:21 accept *:80 accept *:110 accept *:143 reject *:* Am I missing something? I'm wondering why the status page lists this node as non-exit, because it clearly allows outgoing traffic on ports 21,80,110 and 143? See: 'https://gitweb.torproject.org/arma/tor.git/blob_plain/03b9c2cb903cc59f83139039d963f1fdea99b83a:/doc/spec/dir-spec.txt' Exit -- A router is called an 'Exit' iff it allows exits to at least two of the ports 80, 443, and 6667 and allows exits to at least one /8 address space. Also: http://www.mail-archive.com/or-talk@freehaven.net/msg10275.html this explains why the status page does not list the node as an exit node. thanks. But as far as I understand, the node does not get the Exit-Flag, but it is still used for outgoing traffic on the accepted ports? So the main-question is still unanswered. best regars, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Sat, 29 Jan 2011 19:46:20 +0100 Jan Weiher j...@buksy.de wrote: This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: It hasn't shown up in any of the exit scans as suspicious. Lack of contact info isn't a concern. The exit policy is odd, yes. However, arguably those are also very popular ports as well. -- 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: Is gatereloaded a Bad Exit?
Am 29.01.2011 21:44, schrieb Andrew Lewman: On Sat, 29 Jan 2011 19:46:20 +0100 Jan Weiher j...@buksy.de wrote: This node looks suspicious to me, because there is no contact info given and the exit policy allows only unencrypted traffic: It hasn't shown up in any of the exit scans as suspicious. What kind of scans do you perform? I thought these scans do only check for content manipulation? I dont see how to recognize if the traffic is recorded? Lack of contact info isn't a concern. I think if you run one of the fastest nodes, it is at least very odd not to have a contact info. If you are concerned about your privacy, just go on and create a freemail account somewhere. The exit policy is odd, yes. However, arguably those are also very popular ports as well. Yeah, I'm not saying this is evil, but want to bring it into discussion, because I was unable to get any reasonable explanation for this exitpolicy. Of course these ports are popular, but 443 is popular as well? So for me it looked like pick all the popular _unencrypted_ ports. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Hi and Ubuntu install...
Hi, I am trying to setup Tor on an Ubuntu box, but getting a little glitch on the install - hope this is the correct list to query... I followed the instructions from here: http://www.torproject.org/docs/debian.html.en In particular: Then add this line to your /etc/apt/sources.list file: deb http://deb.torproject.org/torproject.org DISTRIBUTION main where you put the codename of your distribution (i.e. etch, lenny, sid, maverick, lucid, karmic, jaunty, intrepid, hardy or whatever it is) in place of DISTRIBUTION. Then add the gpg key used to sign the packages by running the following commands at your command prompt: gpg --keyserver keys.gnupg.net --recv 886DDD89 I found and installed the package ok, but the gpg line fails - doesnt seem to get to keys.gnupg.net. Is that still current, or is the server just down for now and I should try later... Thanks in advance, Chris *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Sat, Jan 29, 2011 at 09:55:05PM +0100, j...@buksy.de wrote 1.3K bytes in 38 lines about: : What kind of scans do you perform? I thought these scans do only check : for content manipulation? I dont see how to recognize if the traffic is : recorded? https://gitweb.torproject.org/torflow.git/tree/HEAD:/NetworkScanners/ExitAuthority is the code. You are correct in that we cannot detect recording of traffic. : Yeah, I'm not saying this is evil, but want to bring it into : discussion, because I was unable to get any reasonable explanation for : this exitpolicy. : : Of course these ports are popular, but 443 is popular as well? So for me : it looked like pick all the popular _unencrypted_ ports. I agree, it does look that way. People can set ExcludeExitNodes for gatereloaded in their torrc. -- Andrew pgp key: 0x74ED336B *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Question and Confirmation.
On Fri, Jan 28, 2011 at 11:29:25PM +, pump...@cotse.net wrote 2.3K bytes in 53 lines about: : My understanding is that Tor encrypts both the content of a data : packet and also the header. It encrypts the packet and header three : times on the client (my computer) and then at each node one layer is : decrypted until the data packet and header are decrypted to : plaintext at the final exit node (except when TLS is used). Right? Actually, tor wraps the original traffic in encryption and tunnels it through the 3 hops of a circuit. We do not touch the original data. : The Tor FAQ says Tor is not illegal anywhere in the world. Can : that really be the case? What about North Korea for example? Tor : as a specific tool might not be specifically illegal but surely it : would fall under the rubric of some kind of stupid prohibition? North Korea doesn't have Internet, much less personal computers connected to anything. As for the larger question, Tor itself is not illegal that we know of. Circumventing the state-run proxy/firewall may be illegal. However, I'm sure if a Ministry of Culture wants to trump up charges, crimes against the common good or morals is a fine charge to levy on someone in custody. A fine bit of legal research would be to discover in which countries circumventing a national firewall or blocklist is illegal. -- Andrew pgp key: 0x74ED336B *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
I dont see how to recognize if the traffic is recorded? I know people who record exit traffic, lots of it. And they do all sorts of things with it too. Does that news trouble you? If so, you need to readjust your thinking. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
One could argue that recording traffic goes against the spirit of the tor project and anonymity in general. But even if people do monitor the traffic as long as they don't control both nodes there is little chance that the end user can really be tracked. There is also an onus on the end user to still practice safe internet habits and be careful about still using SSL, when they are entering passwords, or doing similar sensitive things. Tor was not designed to make internet browsing safe in a general sense, rather it is meant to provide away around firewalls and censorship so that people can access the open internet without a fear of getting tracked as easy. -Andrew On Jan 29, 2011, at 8:56 PM, grarpamp wrote: I dont see how to recognize if the traffic is recorded? I know people who record exit traffic, lots of it. And they do all sorts of things with it too. Does that news trouble you? If so, you need to readjust your thinking. *** 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: Is gatereloaded a Bad Exit?
On Sat, Jan 29, 2011 at 9:56 PM, grarpamp grarp...@gmail.com wrote: I dont see how to recognize if the traffic is recorded? I know people who record exit traffic, lots of it. And they do all sorts of things with it too. Does that news trouble you? If so, you need to readjust your thinking. It's not realistic to think that people will maintain their own excludelists— a few extremists will, but the bulk of the users won't. Instead, I think that nodes which exit _only_ to the unencrypted version of a service (e.g. 80 but not 443) should be excluded from operating as exits entirely (except as enclaves). In this way these nodes would be force to pay their way. We can't stop them from sniffing, but at least we can make them carry traffic they can't sniff as part of the cost of doing their evil business. They could do things like severely throttle encrypted traffic, but that is activity that testing could detect. To some extent the exit flag criteria approximates this, but it's mostly a load balancing criteria and it's actually really easy to trick, even though this node has not successfully done so. (E.g. Accept 224/4:*) As far as that exit policy goes, the RFC1918 blocks might be there in an ignorant attempt to trigger the exit flag for completely benign reasons, though sniffing sounds more likely. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
Thus spake Gregory Maxwell (gmaxw...@gmail.com): On Sat, Jan 29, 2011 at 9:56 PM, grarpamp grarp...@gmail.com wrote: I dont see how to recognize if the traffic is recorded? Various research groups occasionally experiment with using side channels for detecting recording exits. Their results are not usually reproducible, though (no source code, poor design, poor quality control, too easy to mitigate, etc). :/ They do occasionally find interesting stuff. But then they either publish, or get rejected, and then shut down their code and forget about it. Instead, I think that nodes which exit _only_ to the unencrypted version of a service (e.g. 80 but not 443) should be excluded from operating as exits entirely (except as enclaves). In this way these nodes would be force to pay their way. We can't stop them from sniffing, but at least we can make them carry traffic they can't sniff as part of the cost of doing their evil business. They could do things like severely throttle encrypted traffic, but that is activity that testing could detect. As far as that exit policy goes, the RFC1918 blocks might be there in an ignorant attempt to trigger the exit flag for completely benign reasons, though sniffing sounds more likely. I agree. We already have scripts to detect this, we just have not yet decided to actually use them yet. I believe we should. Currently, 5 nodes exit to *only* plaintext ports for web and email. There are about 50 others that exit to the plaintext versions for web or email. I believe we hould ban these 5 immediately, and consider banning the other 50 after issuing the appropriate announcements. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpE4kMVVEmo8.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Thus spake Mike Perry (mikepe...@fscked.org): Thus spake Gregory Maxwell (gmaxw...@gmail.com): As far as that exit policy goes, the RFC1918 blocks might be there in an ignorant attempt to trigger the exit flag for completely benign reasons, though sniffing sounds more likely. I agree. We already have scripts to detect this, we just have not yet decided to actually use them yet. I believe we should. Currently, 5 nodes exit to *only* plaintext ports for web and email. There are about 50 others that exit to the plaintext versions for web or email. I believe we hould ban these 5 immediately, and consider banning the other 50 after issuing the appropriate announcements. Sorry, the 5 are: NOTICE[Sat Jan 29 20:56:43 2011]:Nodes allowing plaintext but not secure: ElzaTorServer=009E71AED2C5580E942AC1743D1C440C5B2C459E QuantumSevero=4BF2F90E6E1905E2FB4F371E471422150D722A93 gatereloaded=550CC9724FA77C7F9260B93989D22A70654D3B92 oompaloompa=775DF6B8CF3FB0150A594F6E2B5CB1E0AC45D09B oompaloompa2=BABBF0694251E5AFF7BF3A0A02EFDC12CB99B05F -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpCgx8xgRqZn.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Forgive my ignorance but this seeks rather knee-jerk to me. Maybe I'm missing something. Everyone that uses TOR should acknowlege that all data that doesn't use encryption before entering the TOR network. It's even in the FAQ (https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#CanexitnodeseavesdroponcommunicationsIsntthatbad) That means if I go to http://www.somewebsite.com I already acknowedge that someone out there could potentially be monitoring my traffic - regardless of whether I use TOR or not. In other words TOR does not claim to protect against this kind of attack. Furthermore we all acknowledge that any exit node could potentially be monitoring our unencrypted traffic (As Andrew stated earlier You are correct in that we cannot detect recording of traffic.) Finally there is no way that an exit node can directly affect the mode choices by a client. Ie, apart from a particular node existing, there is no way that a node could force a user to use it. Therefore I submit that having these nodes, whether they are overtly recording traffic or not, does not result in any harm to the TOR network. In fact, their presence lessens the burden on the TOR network as they are providing much needed bandwidth. In addition, if a user was to attempt to use encryption then another entirely separate exit node will be used instead (one that has a policy that allows traffic on the specific port) So the user isn't inconvenienced or forced to use an insecure protocol. So, what's the threat? Why are you considering banning these nodes when, by all accounts, I cannot see them having a negative impact on the network as a whole (in fact, it's probably a positive influence) FWIW, none of these nodes are mine. I used to run an exit node but I don't any longer (with my new Internet connection speeds it's not worth it) Eddie On Sun, Jan 30, 2011 at 15:57, Mike Perry mikepe...@fscked.org wrote: Thus spake Mike Perry (mikepe...@fscked.org): Thus spake Gregory Maxwell (gmaxw...@gmail.com): As far as that exit policy goes, the RFC1918 blocks might be there in an ignorant attempt to trigger the exit flag for completely benign reasons, though sniffing sounds more likely. I agree. We already have scripts to detect this, we just have not yet decided to actually use them yet. I believe we should. Currently, 5 nodes exit to *only* plaintext ports for web and email. There are about 50 others that exit to the plaintext versions for web or email. I believe we hould ban these 5 immediately, and consider banning the other 50 after issuing the appropriate announcements. Sorry, the 5 are: NOTICE[Sat Jan 29 20:56:43 2011]:Nodes allowing plaintext but not secure: ElzaTorServer=009E71AED2C5580E942AC1743D1C440C5B2C459E QuantumSevero=4BF2F90E6E1905E2FB4F371E471422150D722A93 gatereloaded=550CC9724FA77C7F9260B93989D22A70654D3B92 oompaloompa=775DF6B8CF3FB0150A594F6E2B5CB1E0AC45D09B oompaloompa2=BABBF0694251E5AFF7BF3A0A02EFDC12CB99B05F -- Mike Perry Mad Computer Scientist fscked.org evil labs -- Eddie Cornejo -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d? s: a C+++ UL+++ P++ L++ E- W+ N- o K- w++ O M-- V PS+ PE Y PGP++ t 5 X+ R tv-- b+ DI D++ G e++ h r+++ y --END GEEK CODE BLOCK-- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
Thus spake Eddie Cornejo (corn...@gmail.com): Forgive my ignorance but this seeks rather knee-jerk to me. Maybe I'm missing something. Yeah, I believe you're missing the fact that these ports also contain plaintext passwords than can be used to gain access to information on these and other accounts that may or may not have ever traveled over tor. That is the difference. Finally there is no way that an exit node can directly affect the mode choices by a client. Ie, apart from a particular node existing, there is no way that a node could force a user to use it. See above. Therefore I submit that having these nodes, whether they are overtly recording traffic or not, does not result in any harm to the TOR network. In fact, their presence lessens the burden on the TOR network as they are providing much needed bandwidth. We don't need bandwidth that bad. So, what's the threat? Why are you considering banning these nodes when, by all accounts, I cannot see them having a negative impact on the network as a whole (in fact, it's probably a positive influence) I believe that allowing these nodes sends a message that we are OK with people monitoring plaintext traffic, because it is anonymized. We have never been OK with this. People use plaintext at their own risk, and yes, they should know better, but this does NOT mean that we are comfortable feeding them to the wolves. If said exits are really interested in helping, they should alter their exit policy to allow encryption and then rekey. They will be banned by identity key, not by IP. Rekeying without fixing the exit policy will just result in IP bans. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpAhAbyOuyIb.pgp Description: PGP signature
Tor 0.2.2.22-alpha is out
Tor 0.2.2.22-alpha fixes a few more less-critical security issues. The main other change is a slight tweak to Tor's TLS handshake that makes relays and bridges that run this new version reachable from Iran again. We don't expect this tweak will win the arms race long-term, but it will buy us a bit more time until we roll out a better solution. Anybody running a relay or bridge who wants it to work for Iran should upgrade. https://www.torproject.org/download/download Changes in version 0.2.2.22-alpha - 2011-01-25 o Major bugfixes: - Fix a bounds-checking error that could allow an attacker to remotely crash a directory authority. Bugfix on 0.2.1.5-alpha. Found by piebeer. - Don't assert when changing from bridge to relay or vice versa via the controller. The assert happened because we didn't properly initialize our keys in this case. Bugfix on 0.2.2.18-alpha; fixes bug 2433. Reported by bastik. o Minor features: - Adjust our TLS Diffie-Hellman parameters to match those used by Apache's mod_ssl. - Provide a log message stating which geoip file we're parsing instead of just stating that we're parsing the geoip file. Implements ticket 2432. o Minor bugfixes: - Check for and reject overly long directory certificates and directory tokens before they have a chance to hit any assertions. Bugfix on 0.2.1.28 / 0.2.2.20-alpha. Found by doorss. signature.asc Description: Digital signature
Re: Is gatereloaded a Bad Exit?
Howdy, Thanks for replying. Yeah, I believe you're missing the fact that these ports also contain plaintext passwords than can be used to gain access to information on these and other accounts that may or may not have ever traveled over tor. That is the difference. Actually, no I acknowledge that. I'm stating that this is a known position. Regardless of whether you ban these nodes or not, ALL nodes have the potential for reading unencrypted traffic. The FAQ I linked clearly mentions this. Finally there is no way that an exit node can directly affect the mode choices by a client. Ie, apart from a particular node existing, there is no way that a node could force a user to use it. See above. Above? I'm sorry but I don't think you've addressed this point. Exit node A can't force user Z to use it. We don't need bandwidth that bad. A matter of opinion, but I'll accept it. I believe that allowing these nodes sends a message that we are OK with people monitoring plaintext traffic, because it is anonymized. We have never been OK with this. Ok, I accept that this might send a message to 50ish nodes (if you ban all 50+) but if someone was so inclined they could still do this by allowing encrypted traffic and throttling it/blocking it outside of TOR (transparent proxy perhaps?) I predict this is worse as the user client will believe node A will honestly relay encrypted traffic and will select it on this basis, only to find their connection is slow or doesn't fully connect. Admitedly, this won't be a huge problem unless a good number of nodes started doing this. People use plaintext at their own risk, and yes, they should know better, but this does NOT mean that we are comfortable feeding them to the wolves. My argument is that you're not identifying wolves. If you were serious about identifying wolves then could I suggest you create some dummy accounts, send your password through all exit nodes individually and see which of your accounts are accessed. This would positively identify wolves. All you're achieving by soley looking at exit policies is identifying things that may or may not be wolves and ignoring the larger body of exit nodes that may or may not include wolves. I submit your testing is flawed. If said exits are really interested in helping, they should alter their exit policy to allow encryption and then rekey. They will be banned by identity key, not by IP. Rekeying without fixing the exit policy will just result in IP bans. I'm not sure I'm comfortable with dictating how an exit nodes exitpolicy should be defined. Each policy should be up to the exit node owner to decide. Just my 2c -- Eddie Cornejo -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d? s: a C+++ UL+++ P++ L++ E- W+ N- o K- w++ O M-- V PS+ PE Y PGP++ t 5 X+ R tv-- b+ DI D++ G e++ h r+++ y --END GEEK CODE BLOCK-- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor 0.2.2.22-alpha is out
Tor 0.2.2.22-alpha fixes a few more less-critical security issues. The main other change is a slight tweak to Tor's TLS handshake that makes relays and bridges that run this new version reachable from Iran again. We don't expect this tweak will win the arms race long-term, but it will buy us a bit more time until we roll out a better solution. Anybody running a relay or bridge who wants it to work for Iran should upgrade. Do you have any plans to apply these tweaks to the 2.1.X stable branch too? Regards, Klaus signature.asc Description: This is a digitally signed message part.
Re: Is gatereloaded a Bad Exit?
Thus spake Eddie Cornejo (corn...@gmail.com): I believe that allowing these nodes sends a message that we are OK with people monitoring plaintext traffic, because it is anonymized. We have never been OK with this. Ok, I accept that this might send a message to 50ish nodes (if you ban all 50+) but if someone was so inclined they could still do this by allowing encrypted traffic and throttling it/blocking it outside of TOR (transparent proxy perhaps?) I predict this is worse as the user client will believe node A will honestly relay encrypted traffic and will select it on this basis, only to find their connection is slow or doesn't fully connect. Admitedly, this won't be a huge problem unless a good number of nodes started doing this. We can detect nodes that fail encrypted connections. We currently scan for failure of port 443. We also detect throttling by virtue of our bw authorities measuring using 443. 443 is the second-most trafficed port by byte on the Tor network, occupying only ~1% of the traffic. If stingy exit nodes really want to waste hours to pinch pennies from their malicious exit policy, they can try crafting a throttling policy that we can't detect. Seems like there are better ways to spend their time. Like reading other people's email. So no, I'm not terribly concerned about second-order effects of this. People use plaintext at their own risk, and yes, they should know better, but this does NOT mean that we are comfortable feeding them to the wolves. My argument is that you're not identifying wolves. If you were serious about identifying wolves then could I suggest you create some dummy accounts, send your password through all exit nodes individually and see which of your accounts are accessed. This would positively identify wolves. All you're achieving by soley looking at exit policies is identifying things that may or may not be wolves and ignoring the larger body of exit nodes that may or may not include wolves. I submit your testing is flawed. We're not trying to identify wolves. We are sending a message to the community. If said exits are really interested in helping, they should alter their exit policy to allow encryption and then rekey. They will be banned by identity key, not by IP. Rekeying without fixing the exit policy will just result in IP bans. I'm not sure I'm comfortable with dictating how an exit nodes exitpolicy should be defined. Each policy should be up to the exit node owner to decide. Just my 2c Not really. In reality, it's up to those who write the code to decide what is available and how it works ;). Welcome to The Golden Path. At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpFPYPp83NMq.pgp Description: PGP signature
Re: Is gatereloaded a Bad Exit?
Jan Weiher wrote: Of course these ports are popular, but 443 is popular as well? So for me it looked like pick all the popular _unencrypted_ ports. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ Maybe the owner of that node is just only a lamer? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
grarpamp wrote: I dont see how to recognize if the traffic is recorded? I know people who record exit traffic, lots of it. And they do all sorts of things with it too. Does that news trouble you? If so, you need to readjust your thinking. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ Is it a serious problem if some of owners of tor-nodes record the exit traffic? It seems to me that the Govermental bodies can do it instead of them and they probably do it in such countries as the US or Germany and etc. If the first is serious problem, why the last is not one? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
Gregory Maxwell wrote: On Sat, Jan 29, 2011 at 9:56 PM, grarpamp grarp...@gmail.com wrote: Instead, I think that nodes which exit _only_ to the unencrypted version of a service (e.g. 80 but not 443) should be excluded from operating as exits entirely (except as enclaves). In this way these nodes would be force to pay their way. We can't stop them from sniffing, but at least we can make them carry traffic they can't sniff as part of the cost of doing their evil business. They could do things like severely throttle encrypted traffic, but that is activity that testing could detect. Where I can read what it means a bad exit? Earlier I thought that it is and exit which works wrong in something. And I thought that them excludes from routing. But I pereodically can see that my client establish connections through bad exits. Have I to need do something from preventing it for protection of my anonimity? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
