On 07/09/2007, David Gerard dgerard@gmail.com wrote:
On 07/09/07, David Gerard dgerard@gmail.com wrote:
You can edit Wikipedia securely from here: https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page It's slower, but the connection is SSL, so can't be snooped - only the fact of a transaction can be snooped. Your IP will show up in the server logs, so will be viewable by Wikimedia sysadmins or by those with checkuser, but it's as secure as we can do.
Note also this is a bit beta, so check you're still logged in as you and so on before you hit "edit". (You may wish to choose a different skin to Monobook to give a clear visual clue as to whether you're logged in.)
- d.
There are different types of security. TLS will obscure the contents of the packet (most notably, the one's password), but not packet header, which includes routing information, such as IP addresses.
Tor will 'hide' routing information by using a series of nodes - so each node replaces the routing information with it's own. (Basically, if Alice can talk to Carol and Carol can talk to Bob, then Carol can talk to Bob on behalf of Alice.) Layered encryption is used to prevent any of the Tor nodes from knowing the full circuit. Tor still has some vulnerabilities, but it takes significant resources to exploit them - more than the average packet sniffer has.
You might be interested in the Nym software, which issues a certificate corresponding to a particular IP address - theoretically a scarce, non-proxy one. A user could then use Tor with that certificate, a nym, presenting that nym to a service. The service could then block the user's nym.
And no, Thomas, packet sniffing is not hard. It does, however, require an opportune position on the network.
On 9/7/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
And no, Thomas, packet sniffing is not hard. It does, however, require an opportune position on the network.
...Which tor gives to any fool who wants to enable the exit node functionality of the tor software on his system...
(In other words if you are you ever *view* Wikipedia via tor and you happen to be logged in your identity will be available for free use by whatever unknown random person runs the exit that you are randomly routed to. If you're an admin you might find yourself replacing the mainpage with goatse...)
Gregory Maxwell wrote:
On 9/7/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
And no, Thomas, packet sniffing is not hard. It does, however, require an opportune position on the network.
...Which tor gives to any fool who wants to enable the exit node functionality of the tor software on his system...
(In other words if you are you ever *view* Wikipedia via tor and you happen to be logged in your identity will be available for free use by whatever unknown random person runs the exit that you are randomly routed to. If you're an admin you might find yourself replacing the mainpage with goatse...)
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
Unless you are editing through the SSL version. I've started doing that even though I don't use proxies, I don't think it's a bad idea for admins (at least) to use it. I've noticed very little difference in speed, certainly not enough to be bothersome.
On 9/8/07, Todd Allen toddmallen@gmail.com wrote:
Unless you are editing through the SSL version. I've started doing that even though I don't use proxies, I don't think it's a bad idea for admins (at least) to use it. I've noticed very little difference in speed, certainly not enough to be bothersome.
Until you accidentally follow one of the zillion URLs that take you back to non-secure if you're logged in there. :)
As far as speed goes if you're using TOR SSL is the least of your speed worries.
Too bad the tor local exit stuff has to be on an exact IP match, otherwise it would be easy enough to run our own exits to at least remove that terrible sniffing problem from tor for our traffic.
On 9/8/07, Gregory Maxwell gmaxwell@gmail.com wrote:
On 9/8/07, Todd Allen toddmallen@gmail.com wrote:
Unless you are editing through the SSL version. I've started doing that even though I don't use proxies, I don't think it's a bad idea for admins (at least) to use it. I've noticed very little difference in speed, certainly not enough to be bothersome.
Until you accidentally follow one of the zillion URLs that take you back to non-secure if you're logged in there. :)
So don't ever log in to the non-secure one.
As far as speed goes if you're using TOR SSL is the least of your speed worries.
I wonder if running Wikipedia as a tor hidden service would improve the speed. It'd at least spread the traffic more evenly as there'd be no need to find an exit node with an appropriate exit policy.
Too bad the tor local exit stuff has to be on an exact IP match, otherwise it would be easy enough to run our own exits to at least remove that terrible sniffing problem from tor for our traffic.
145.97.39.155 isn't the only ip address for en.wikipedia.org? How many are there?
On 08/09/2007, Anthony wikimail@inbox.org wrote:
On 9/8/07, Gregory Maxwell gmaxwell@gmail.com wrote:
As far as speed goes if you're using TOR SSL is the least of your speed
worries.
I wonder if running Wikipedia as a tor hidden service would improve the speed. It'd at least spread the traffic more evenly as there'd be no need to find an exit node with an appropriate exit policy.
Tor's speed is getting faster, for the record. With Mike Perry's new load balancing, Tor should have four times the capacity once the network rebalances - i.e. after a number or people have upgraded to the latest versions. http://archives.seul.org/or/talk/Sep-2007/msg00005.html
And no, running Wikipaedia as a Tor hidden service would definitely not improve speed - remember that hidden services are designed to anonymise the server, not just the client. It would be slower... but then if you care about speed and not security, I recommend you don't use Tor.
Running Wikipaedia as a hidden service would, however, provide a number of security benefits. For example, end-to-end encryption, better than SSL/TLS, in my opinion - for all of those admins using Tor y'all are apparently concerned about. One IP for checkusers to check, if checkusers feel the need to find out what sorts of edits admins are making through Tor. (This also assumes Wikipaedia is doing a good job blocking Tor, which it isn't. The Tor developers gave you the code to generate a list of Tor nodes exiting to Wikipaedia, use it.)
Too bad the tor local exit stuff has to be on an exact IP match, otherwise it would be easy enough to run our own exits to at least remove that terrible sniffing problem from tor for our traffic.
Again, hidden services provide high quality end-to-end encryption. Or stick with TLS.
145.97.39.155 isn't the only ip address for en.wikipedia.org? How many are there?
145.97.39.155 is rr.knams.wikimedia.org
en.wikipedia.org is 66.230.200.100 which is also rr.pmtpa.wikimedia.org
On 9/8/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
145.97.39.155 isn't the only ip address for en.wikipedia.org? How many are there?
145.97.39.155 is rr.knams.wikimedia.org
en.wikipedia.org is 66.230.200.100 which is also rr.pmtpa.wikimedia.org
These are LVS VIPs. I suspect that we could put in some sort of rewrite rules on the LVS hosts to redirect TOR traffic to some dedicated tor exit nodes which only allow traffic to reach back to the local LVS.
I.e. to the outside world the TOR exits would look they are on 145.97.39.155 (knams), 66.230.200.100 (tampa), and 203.212.189.253 (yaseo), and 66.230.200.219 (secure). They would really be on other addresses. Their exit policies would allow traffic to :80 and :443 on their apparent external addresses. This should be enough to cause TOR to send all Wikipedia traffic to these exits.
We could apply whatever blocking policy we want for TOR to the 3-4 actual exit source IPs.
This would have the following advantages: 1) Less tor blocking inconsistency. (We often have only half the active Tor exists blocked from, which means that regular tor users can't edit via tor but sneaky trolls can... some exist are soft blocked, some are hard blocked, many are not blocked at all)
2) Improved security for users who use tor. No more risk of sniffing by naughty exit node operators.
3) Improved performance for tor users since there will be low latency between the exit and our caches.
Even though allowing editing from Tor is a matter which rational people can debate... allowing people to read via tor is something we should support as strongly as possible.
On 09/09/2007, Gregory Maxwell gmaxwell@gmail.com wrote:
These are LVS VIPs. I suspect that we could put in some sort of rewrite rules on the LVS hosts to redirect TOR traffic to some dedicated tor exit nodes which only allow traffic to reach back to the local LVS.
I.e. to the outside world the TOR exits would look they are on 145.97.39.155 (knams), 66.230.200.100 (tampa), and 203.212.189.253 (yaseo), and 66.230.200.219 (secure). They would really be on other addresses. Their exit policies would allow traffic to :80 and :443 on their apparent external addresses. This should be enough to cause TOR to send all Wikipedia traffic to these exits.
We could apply whatever blocking policy we want for TOR to the 3-4 actual exit source IPs.
This would have the following advantages:
- Less tor blocking inconsistency. (We often have only half the
active Tor exists blocked from, which means that regular tor users can't edit via tor but sneaky trolls can... some exist are soft blocked, some are hard blocked, many are not blocked at all)
Simply use the Python exitlist code or TorDNSEL, both provided courtesy of the Tor developers. http://exitlist.torproject.org/ http://cvs.seul.org/viewcvs/viewcvs.cgi/tor/trunk/contrib/exitlist?rev=10402... These may also be of interest: http://www.imperialviolet.org/binary/mediawiki-1.4.4-tor-block.patch http://archives.seul.org/or/talk/May-2005/msg00128.html http://archives.seul.org/or/talk/Sep-2005/msg00312.html http://en.wikipedia.org/wiki/Wikipedia:Requests_for_adminship/TawkerbotTorA
- Improved security for users who use tor. No more
risk of sniffing by naughty exit node operators.
For a logged in Tor user (an admin, I guess). Or one could theoretically set up a hidden service, which offers end-to-end encryption.
- Improved performance for tor users since there will be low latency
between the exit and our caches.
Not my primary concern, but Tor is getting better.
Even though allowing editing from Tor is a matter which rational people can debate... allowing people to read via tor is something we should support as strongly as possible.
: )
On 0, Gregory Maxwell gmaxwell@gmail.com scribbled:
On 9/8/07, Todd Allen toddmallen@gmail.com wrote:
Unless you are editing through the SSL version. I've started doing that even though I don't use proxies, I don't think it's a bad idea for admins (at least) to use it. I've noticed very little difference in speed, certainly not enough to be bothersome.
Until you accidentally follow one of the zillion URLs that take you back to non-secure if you're logged in there. :)
But if you're using secure.wikimedia, would you be logged in on en.wikipedia? As I've said, I've been editing through the former for some months now, and whenever I am sent to an en.wikipedia.org link, I'm not logged in.
As far as speed goes if you're using TOR SSL is the least of your speed worries.
Yes, that's definitely true. Every little bit helps though, and if you are running a server, you actually get really good browsing speed - subjectively, I felt like my Tor browsing no more than halved (or less on a good day!) the speed when I was running a server. I still don't know whether this is because it cut out a hop (since the server was now on the local machine) or because my traffic was somehow being favored.
-- gwern security Ortega Firewalls propaganda 5707 b underground imapct Security Spall
On 08/09/2007, Gwern Branwen gwern0@gmail.com wrote:
On 0, Gregory Maxwell gmaxwell@gmail.com scribbled:
As far as speed goes if you're using TOR SSL is the least of your speed
worries.
Yes, that's definitely true. Every little bit helps though, and if you are running a server, you actually get really good browsing speed - subjectively, I felt like my Tor browsing no more than halved (or less on a good day!) the speed when I was running a server. I still don't know whether this is because it cut out a hop (since the server was now on the local machine) or because my traffic was somehow being favored.
Interesting - if anything, I've noticed a performance degradation from running Tor as a server.
Is it possible you upgraded to one of the lastest versions of Tor at the same time you started running a server? The latest versions include improved load balancing which should make Tor much faster. http://archives.seul.org/or/talk/Sep-2007/msg00005.html
There is a proposal for cutting out a node from the circuit for those running non-exit servers. I don't think it's been implemented, but you can read about it here: http://archives.seul.org/or/dev/Jun-2007/msg00059.html http://tor.eff.org/svn/trunk/doc/spec/proposals/116-two-hop-paths-from-guard...
On 08/09/2007, Gregory Maxwell gmaxwell@gmail.com wrote:
On 9/7/07, Armed Blowfish diodontida.armata@googlemail.com wrote:
And no, Thomas, packet sniffing is not hard. It does, however, require an opportune position on the network.
...Which tor gives to any fool who wants to enable the exit node functionality of the tor software on his system...
Hey, I run an exit node, and I don't sniff the traffic.
Note that the exit node can only sniff the IP of the middle node and the contents of the traffic itself - NOT the routing information of the client. This is assuming, of course, that the exit node operator is not performing a Sybil attack on Tor, i.e. running more than one node in the client's circuit. Entry node and exit node, combined with a latency timing attack against the middle node, should provide the equivalent of regular packet sniffing, but is much harder to do, especially if the client is using guard nodes, which substantially reduce the chance of this happening.
(In other words if you are you ever *view* Wikipedia via tor and you happen to be logged in your identity will be available for free use by whatever unknown random person runs the exit that you are randomly routed to. If you're an admin you might find yourself replacing the mainpage with goatse...)
Are you talking about session (cookie) stealing or password stealing?
If an admin were theoretically using Tor, which is quite possible because all admins have ipblock-exempt, said admin could, as others have suggested, log in via TLS Wikipaedia. Of course, TLS has vulnerabilities, but unless the attacker is particularly determined and resourceful it should be good enough.
Still, if you are worried, you could tell Tor to limit itself to a given set of exit nodes - preferably trusted ones. However, any random set of a limited number of exit nodes will reduce your probability of being sniffed, since rather than having to be any random exit node you happen to use, the attacker would have to be lucky to be one of the few exit nodes that you use. This would reduce your anonymity (which becomes pseudonymity if you log in to Wikipaedia), but it would also reduce the chance of sending your password by a malicious attacker.
Changing one's password on a frequent basis is also a good security practise.