Relay flooding, confirmation, HS's, default relay, web of trust
Some further thoughts on an already mixed thread... Would this increase anonymity? As pointed out previously, not much. Attacks against Tor anonymity usually relate to entry-point/exit-point traffic correlation... Regardless of how many segments are in the middle, if your adversary can corner the market on exit nodes, it doesn't matter how many intermediate relay nodes you're using. (Correct me where I'm wrong, experts) Ahh, ok, I see, entry-exit correlation/tagging/timing/confirmation... interesting. I guess a longer path length could only help a quite tiny amount with that by adding some jitter, packet loss, dead circuit churn, etc in between. It certainly directly helps a lot against those entities trying to do simple hop by hop flow/log requests. Non-exit relay by default wouldn't help regarding the exit part as no one's suggesting turning up new exit relays by default. But it could add more guards making observing any useful subset of them costlier. But also make the less traffic in them more likely to be yours. And what if the oponnent runs a hidden service trap?... seems that then just watching or running the client's entry guard [1] is all that is needed to confirm both connection and content? Yipes?!!! I'm no expert. This sounds like a very hard and real problem. Thanks! [1] One single lucky node, not two, the trap serves as the exit watchpoint as well. Would this increase the health of the overall network? Yes*! Are there anonymity drawbacks to having a glut of available bandwith? Or a glut of legit nodes? Or both? I've not yet considered that in my suggestion of a model in which Tor can in fact be used for bulk/P2P transfer and remain resource healthy. Or, as mentioned earlier, we can assign an OR a level of trust commensurate with its age? Maybe there would also be benefit in a web of trust amongst nodes not unlike a keysigning party. As with social networking, people vouch for each other in various ways and strengths based on how they feel that person meets them. I don't see any reason why node operators [descriptors] could not keysign and have that web encoded into the descriptors, directories, DHT, etc. Degrees of separation could also be encoded, and no web is impenetrable. So it would be just one more means of scoring nodes. The sigs would be saying: Hey, I know this operator in real life or online. They have the skill to run an up to date, reasonably secure node and at least check for cold compromise once in a while. And I would be reasonably comfortable were my traffic to transit their node, excepting of course lawful order or coercion. As before, loose, just another means. Also, symmetry of up/down bandwidth can be an issue too... which is unfortunate. Issue? A non-exit relay runs the same bitrate in and out of its interface, bytes in, bytes out, over time, it's impossible not to. So your maximum giveback is limited to the lower of your asymmetrical rates because you'll saturate the slower side at any greater rate. The unfortunate thing about it is that all four of economies, tech, policies and outright supression conspire to make asymmetry what you see in the consumer market. As opposed to cable (and various RF tech and fiber PON's), fiber and dsl aren't really tech limited to asymmetry. So you're just seeing the other three in action there. Protest, buy more, or co-op and trench your own neighborhood :) s/hit/hip/ ;) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Configuring a Hidden Service
* zzzjethro...@email2me.net schrieb am 2010-12-06 um 08:19 Uhr: If your computer isn't online all the time, your hidden service won't be either. This leaks information to an observant adversary. Does it leak because it is online all the time or because it isn't online all the time? And how or what does it leak? Assume you run a webserver on your local machine. You configured it as hidden service. In the morning when you wake up. you turn on your computer and the hidden service is available to the world. Before you go to bed, you turn off your computer and the hidden service disappears. An attacker can send requests to your hidden service to check if it is online. He will learn that it is turned off for some hours and online for some hours. With this information he knows (or can assume) in which timezone your computer is located and maybe some more. Also, does one need to be connected (online), to the Tor network in order to precheck a Hidden Services site in order to make sure it is working properly? Can it open in Firefox browser offline and whatever You need to be connected with the Tor Network, because your software needs to connect to certain servers (introduction and rendezvous points, i.e.). regards, -- Jens Kubieziel http://www.kubieziel.de Wer viel Charakter hat, hat wenig Eigentum. John James Osborne signature.asc Description: Digital signature
Re: Relay flooding, confirmation, HS's, default relay, web of trust
On Mon, 6 Dec 2010, grarpamp wrote: And what if the oponnent runs a hidden service trap?... seems that then just watching or running the client's entry guard [1] is all that is needed to confirm both connection and content? Yipes?!!! I'm no expert. This sounds like a very hard and real problem. Thanks! [1] One single lucky node, not two, the trap serves as the exit watchpoint as well. I'm too obtuse to understand, just with your footnote alone, what a hidden service trap is - would you provide a further explanation, or a link to one ? Maybe there would also be benefit in a web of trust amongst nodes not unlike a keysigning party. As with social networking, people vouch for each other in various ways and strengths based on how they feel that person meets them. I don't see any reason why node operators [descriptors] could not keysign and have that web encoded into the descriptors, directories, DHT, etc. I proposed early in the previous thread that not only should a web of trust be considered, but that this was indeed a classic case of a web of trust ... I didn't see any comment on this from the Big Names on the list, though... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Relay flooding, confirmation, HS's, default relay, web of trust
On Mon, Dec 06, 2010 at 05:18:21PM +, John Case wrote: I proposed early in the previous thread that not only should a web of trust be considered, but that this was indeed a classic case of a web of trust ... I didn't see any comment on this from the Big Names on the list, though... I think it is an excellent idea (I've suggested that much in the past IIRC). -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Relay flooding, confirmation, HS's, default relay, web of trust
On 2010-12-06 09:18, John Case wrote: On Mon, 6 Dec 2010, grarpamp wrote: [...] Maybe there would also be benefit in a web of trust amongst nodes not unlike a keysigning party. As with social networking, people vouch for each other in various ways and strengths based on how they feel that person meets them. I don't see any reason why node operators [descriptors] could not keysign and have that web encoded into the descriptors, directories, DHT, etc. I proposed early in the previous thread that not only should a web of trust be considered, but that this was indeed a classic case of a web of trust ... I didn't see any comment on this from the Big Names on the list, though... The Web of Trust (WoT) concept provides for marginal security benefits and then only in a very narrow set of circumstances that are unlikely to hold true for the larger community of Tor node operators. Starting with the second point, the WoT concept presumes that trust between its members precedes the codification of that trust into attestations attached to digital certificates. In other words, the WoT might provide (but likely will not) security benefits to a group of users that have pre-existing social relations and trust. For example, members of a human rights group that have personally known each other, or at least the bulk of each other, for years. The WoT cannot provide security benefits to a group of users with no pre-existing social trust relationship, such as the set of Tor node operators. The thousands of Tor node operators, a tiny percentage of which have an existing social relationship, have no inherent trust amongst each other. And how could they? Absent an existing real-life WoT, there is no digital WoT to codify. Even within a group that has a strong existing trust and social graph in real life, the digital codification of a WoT offers security benefits only at the extreme margins. This fact is easiest explained by example: o Fire up your preferred OpenPGP software. (If you don't have OpenPGP software, then your understanding of how a WoT works is likely different from what a WoT actually does). o Eliminate all public keys for users with whom you do not intend to communicate. (No communication security system can provide security benefits to communications that will never take place). o List the public keys that show as valid. (Meaning they are signed by one or more keys that you trust to some degree). o Eliminate all the public keys that are signed by your key. (Those keys are not authenticated by the WoT, they were authenticated by you directly). o Eliminate all the public keys that are signed by keys that you chose to trust because they are the equivalent of CA root keys. This includes Debian distribution signing keys, the keys of any commercial CA, and the signing keys of auto-responder key servers such as the PGP Global Directory. (Signatures performed by such keys do not employ the WoT). o Look at the small number of public keys remaining. The keys are likely from deep inside your social circle. Now eliminate all the public keys that you could trivially authenticate directly, such as by asking a key holders, who are well known to you, to provide you with their key's fingerprint at work, at the next security conference, or the next time you meet at the pub. (The WoT may have authenticated those keys, but the WoT was not necessary to do so since you could have trivially authenticated those few keys yourself). o Lastly, count the remaining public keys. The number will likely be zero (no real life benefit to the WoT) or close to zero (benefit only in the extreme margins). In summary, the WoT is not a suitable solution to increasing the security of the Tor network. --Lucky Green *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Relay flooding, confirmation, HS's, default relay, web of trust
On Mon, 6 Dec 2010, Lucky Green wrote: The Web of Trust (WoT) concept provides for marginal security benefits and then only in a very narrow set of circumstances that are unlikely to hold true for the larger community of Tor node operators. Starting with the second point, the WoT concept presumes that trust between its members precedes the codification of that trust into attestations attached to digital certificates. In other words, the WoT might provide (but likely will not) security benefits to a group of users that have pre-existing social relations and trust. For example, members of a human rights group that have personally known each other, or at least the bulk of each other, for years. Understood. I thik this is worth implementing as a feature - a handful of known nodes begets a handful^2 of trusted nodes, and pretty soon a relatively small organization has a relatively large trusted network. It may not be suitable for you, or for me, but it would be suitable for some... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Dmytrij's anonymous VPS
From http://www.bitcoin.org/smf/index.php?topic=1905.0 - quote - Hello bitcoiners, I'm investigating if here is a demand for anonymous VPS (virtual private servers) service. I have multicore beast server lying around, many years experiences with linux administration and also experiences with Tor hidden services. I was thinking about anonymous VPS many years before. There were attemps to do on Tor network, but payments were always problem. There were some free hostings, but quality was always poor. I found bitcoins recently and now feel I have all pieces to do VPS hosting powerful and thanks to bitcoins - really anonymous. My idea is simple - provide no question service. I don't know my customers is and customers don't know who I am. This is huge advantage in contrast to Vekja because nobody know where the server is located and how to shut down it. I provide 1 or more CPU cores, few hundreds MB RAM and few onion addresses routed to VPS ports. Customer will send me few bitcoins every week. Simple. Only one pitfail is here. Because of strong anonymity, all inbound and outbound traffic is routed to Tor network. No direct connection to Internet. Never. It makes system management slower, but anonymity is the main concern. Users can access server using Tor network or directly from Internet using great service http://tor2web.com/ (hidden services are indexed by Google). Price. My offer is 1 core @ 3GHz and 512MB RAM, SLA 99% (minus glitches on Tor network) for 30 bitcoins per week. But I'm open to discussion here for first users. I need at least 3 users to pay housing. Please comment here or send me anonymous message to https://privacybox.de/dmytrij.msg I swear to send 20% of bitcoins to providers of torservers.net and tor2web.com. First one because they are Tor relay providers accepting bitcoins and second one cause their service is needed for my anonymous VPS. They do not accept bitcoins yet, but I expect it is temporary Smiley. Cheers, Dmytrij *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Relay flooding, confirmation, HS's, default relay, web of trust
I'm too obtuse to understand, just with your footnote alone, what a hidden service trap is - would you provide a further explanation, or a link to one ? A hidden service trap is a hidden service run by any one/entity you'd rather not be doing business with. A trap, a lure, a ruse, a sting. Leading to possible incrimination, characterization, etc... bridging same into the non-anonymous real world. Could be a Bad/Good dude/thing, depending on your point of view. Lucky Green on WoT Oh yes, agreed, I never claimed signing into OpenPGP WoT was magic solution. I littered it with soft disclaimers. As before, it would be an *additional* metric which could optionally be used in selection calculations if desired. Save for a few, the node owners are mostly known only by IP. One might feel better if there was a human keychain wrapped around some of them. Many of us fully understand the weakness of such a WoT as applied to Tor, for which there's no requirement to elect to use its metrics. Much as one may or may not choose to utilize nodes that appear to reside in certain countries, appear to run on certain platforms, have cute nicknames, etc. Were I to be running a node, maybe I'd sign others based on whatever I felt they meant to me. Maybe others would similarly sign mine. Maybe the EFF would sign some, maybe Tor, maybe CCC, maybe torservers, maybe people on mailing lists, maybe FOSS devs, etc, the usual. And maybe I'd let degree of separation from me or them be a weighted guide as to the rest. It's just another tool to use, not magic. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Dmytrij's anonymous VPS
I would be interested. But how anonymous are bitcoins? With traditional money, only the government gets to watch you spend it. With BitCoin, now the entire community gets to watch! On Mon, 06 Dec 2010 22:01 +0100, Moritz Bartl mor...@torservers.net wrote: From http://www.bitcoin.org/smf/index.php?topic=1905.0 - quote - Hello bitcoiners, I'm investigating if here is a demand for anonymous VPS (virtual private servers) service. I have multicore beast server lying around, many years experiences with linux administration and also experiences with Tor hidden services. I was thinking about anonymous VPS many years before. There were attemps to do on Tor network, but payments were always problem. There were some free hostings, but quality was always poor. I found bitcoins recently and now feel I have all pieces to do VPS hosting powerful and thanks to bitcoins - really anonymous. My idea is simple - provide no question service. I don't know my customers is and customers don't know who I am. This is huge advantage in contrast to Vekja because nobody know where the server is located and how to shut down it. I provide 1 or more CPU cores, few hundreds MB RAM and few onion addresses routed to VPS ports. Customer will send me few bitcoins every week. Simple. Only one pitfail is here. Because of strong anonymity, all inbound and outbound traffic is routed to Tor network. No direct connection to Internet. Never. It makes system management slower, but anonymity is the main concern. Users can access server using Tor network or directly from Internet using great service http://tor2web.com/ (hidden services are indexed by Google). Price. My offer is 1 core @ 3GHz and 512MB RAM, SLA 99% (minus glitches on Tor network) for 30 bitcoins per week. But I'm open to discussion here for first users. I need at least 3 users to pay housing. Please comment here or send me anonymous message to https://privacybox.de/dmytrij.msg I swear to send 20% of bitcoins to providers of torservers.net and tor2web.com. First one because they are Tor relay providers accepting bitcoins and second one cause their service is needed for my anonymous VPS. They do not accept bitcoins yet, but I expect it is temporary Smiley. Cheers, Dmytrij *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Dmytrij's anonymous VPS
This is only interesting if you are not on the Internet. Either VPS server as a hidden service, or otherwise Tor only or you set up a parallel (local ?) network. Otherwise, you're just an ISP, no matter what kind of bread crumbs you take as payment, and the hammer is going to come down on things that call themselves ISPs. Think banking rules, but with no big cartel to keep them (relatively) industry friendly. On Mon, 6 Dec 2010, Theodore Bagwell wrote: Date: Mon, 06 Dec 2010 14:55:00 -0800 From: Theodore Bagwell torus...@imap.cc Reply-To: or-talk@freehaven.net To: or-talk@freehaven.net Subject: Re: Dmytrij's anonymous VPS I would be interested. But how anonymous are bitcoins? With traditional money, only the government gets to watch you spend it. With BitCoin, now the entire community gets to watch! On Mon, 06 Dec 2010 22:01 +0100, Moritz Bartl mor...@torservers.net wrote: From http://www.bitcoin.org/smf/index.php?topic=1905.0 - quote - Hello bitcoiners, I'm investigating if here is a demand for anonymous VPS (virtual private servers) service. I have multicore beast server lying around, many years experiences with linux administration and also experiences with Tor hidden services. I was thinking about anonymous VPS many years before. There were attemps to do on Tor network, but payments were always problem. There were some free hostings, but quality was always poor. I found bitcoins recently and now feel I have all pieces to do VPS hosting powerful and thanks to bitcoins - really anonymous. My idea is simple - provide no question service. I don't know my customers is and customers don't know who I am. This is huge advantage in contrast to Vekja because nobody know where the server is located and how to shut down it. I provide 1 or more CPU cores, few hundreds MB RAM and few onion addresses routed to VPS ports. Customer will send me few bitcoins every week. Simple. Only one pitfail is here. Because of strong anonymity, all inbound and outbound traffic is routed to Tor network. No direct connection to Internet. Never. It makes system management slower, but anonymity is the main concern. Users can access server using Tor network or directly from Internet using great service http://tor2web.com/ (hidden services are indexed by Google). Price. My offer is 1 core @ 3GHz and 512MB RAM, SLA 99% (minus glitches on Tor network) for 30 bitcoins per week. But I'm open to discussion here for first users. I need at least 3 users to pay housing. Please comment here or send me anonymous message to https://privacybox.de/dmytrij.msg I swear to send 20% of bitcoins to providers of torservers.net and tor2web.com. First one because they are Tor relay providers accepting bitcoins and second one cause their service is needed for my anonymous VPS. They do not accept bitcoins yet, but I expect it is temporary Smiley. Cheers, Dmytrij *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html *** 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: Arm Release 1.4.0
On Mon, Dec 06, 2010 at 10:25:39AM -0800, Damian Johnson wrote: Hazaa, many thanks for the patches! Committed with the exception of sockstat2 (see below). http://www.atagar.com/transfer/tmp/arm_bsdTest2.tar.bz2 One unrelated problem I noticed is that Arm tends to show local connections as Outbound. Netstat, lsof, etc doesn't include a notion of the directionality of a connection, so I'm using the local port to determine if it's inbound or outbound. If it matches the ORPort or DirPort then it's inbound, otherwise it's outbound (line 323 of the connPanel.py [1]). Do you know a smarter way of handling this? I'm familiar with Linux's chroot jail environments (where this works), but not that details of what the bsd counterpart does. Given that the connection doesn't leave the system, replacing the Tor jail IP address with the public IP address of the gateway is a bit confusing. Sorry, I'm not following. Why isn't the tor connection leaving the system? I'm using the results of 'GETINFO address' which tends to be a lot more helpful than showing the ip on the local network (though I can include an option to display the local address instead if you'd like). FreeBSD jails resemble linux jails mainly by name :), and most probably have an own IP somewhere within RFC 1918. This IP serves as the internal adress to the jail when called from a local subnet, and may show multiple connections to the SocksPort, usually IP:9050. This is, what it looks like: [Host's public gateway IP address scrubbed]:9050 -- scrubbed 0.0s (OUTBOUND) And what it 'SHOULD NEITHER' but with proper IP look like: [Jail's private IP address scrubbed]:9050 -- scrubbed 0.0s (OUTBOUND) These connections are 'inbound' to the jail's SocksPort from the host or a private subnet. Also, when running Arm outside the Tor jail, the Tor configuration file isn't found. See the features.pathPrefix entry in the sample armrc [2]. It's specifically for jail environments (arm will otherwise also be failing to find tor's state, log file, and some other resources used to prepopulate data). If you have a suggestion for an automatic method for determining the jail path then I'm all ears. so arm is trying to read a torrc on the host in the location it knows which is displayed from the jail, but is ignoring the jail flag. I'm attempting to read the torrc from the location Tor reports (via 'GETINFO config-file'), using the features.pathPrefix as... well, a path prefix. I'm not familiar with a method of getting the jail path for Linux jails. Is this information available for bsd jails? I'm happy to help with a patch to autodetect for bsd jails if you have a suggestion for how. 'GETINFO config-file' will show the path to torrc from within the jail. So arm tries to read: /path/to/torrc The location from the host though would be /path/to/jail/path/to/torrc Reading the file in that way, I believe, is not a good idea. All this only applies for systems running Tor in a jail and arm from the host. Arm works nicely with Tor if both are running on the same host or inside a jail on FreeBSD. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
This IP serves as the internal adress to the jail when called from a local subnet, and may show multiple connections to the SocksPort, usually IP:9050. Sorry, I'm not sure if I'm following. You're saying that the check should essentially be: if (localPort == ORPort or localPort == DirPort): # treat as an inbound connection with the external ip # this is part of arm's current behavior elif (localPort == SocksPort and OS == FreeBSD): # treat as an inbound connection with the internal ip (ie, what's reported by sockstat) # this is new to fix the issue you mention else: # treat as an outbound connection # again, part of arm's current behavior ... right? If not, could you please clarify? 'GETINFO config-file' will show the path to torrc from within the jail. So arm tries to read: /path/to/torrc The location from the host though would be /path/to/jail/path/to/torrc Reading the file in that way, I believe, is not a good idea. All this only applies for systems running Tor in a jail and arm from the host. Arm works nicely with Tor if both are running on the same host or inside a jail on FreeBSD. If you set features.pathPrefix /path/to/jail in your armrc then it'll read: /path/to/jail/path/to/torrc like you wanted. Again, if you have an approach for arm to detect that (a) Tor exists in a BSD jail and (b) what its path is then I'd be happy to make it work by default instead. Cheers! -Damian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
On Mon, Dec 06, 2010 at 06:26:10PM -0800, Damian Johnson wrote: if (localPort == ORPort or localPort == DirPort): # treat as an inbound connection with the external ip # this is part of arm's current behavior elif (localPort == SocksPort and OS == FreeBSD): # treat as an inbound connection with the internal ip (ie, what's reported by sockstat) # this is new to fix the issue you mention Yes, and maybe just ignore them. IMHO there's no point in seeing these. else: # treat as an outbound connection # again, part of arm's current behavior ... right? If not, could you please clarify? 'GETINFO config-file' will show the path to torrc from within the jail. So arm tries to read: /path/to/torrc The location from the host though would be /path/to/jail/path/to/torrc Reading the file in that way, I believe, is not a good idea. All this only applies for systems running Tor in a jail and arm from the host. Arm works nicely with Tor if both are running on the same host or inside a jail on FreeBSD. If you set features.pathPrefix /path/to/jail in your armrc then it'll read: /path/to/jail/path/to/torrc like you wanted. Again, if you have an approach for arm to detect that (a) Tor exists in a BSD jail and (b) what its path is then I'd be happy to make it work by default instead. Well, I personally do not like anything reading files in a jail in that way and can do without this particular feature. And if, setting 'features.pathPrefix /path/to/jail' will get the desired results. Thanks Damian, thanks Fabian Regards P.S. wonder where the list sentinels will start to grumble on this ... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
