Re: [freenet-support] Freenet speed & local threats
On Sun, 11 Dec 2011 22:26:50 -0500, Chris wrote: > [...] > If you go out and publicly denounce a rouge government you are liable > to get yourself shot long before you have any chance to gather > support. The Internet is a great platform to anonymously gather > support. When everybody comes out at once to support a cause you > won't be shot. There will be too many others for them to notice. This is why I specifically said that your friends and family are where the battle is really at -- not some impersonal public demonstration in front of the bad guys' palace. (If your friends are online, then Freenet is useful. If you expect to teach online strangers, then I believe you will probably fail. Speaking from (extensive!) personal experience :p.) I don't believe "rogue governments" exist. They are all supported by the majority -- probably via ignorance -- but supported nonetheless. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet speed & local threats
> On Sun, 11 Dec 2011 20:05:36 -0500, Chris wrote: >> > On Sun, 11 Dec 2011 16:36:53 -0500, Chris wrote: >> >> How many users actually compile it themselves? >> > >> > Me, and all other Gentoo users :-). >> > >> >> How many examine the diffs? >> > >> > I do, rarely :s. >> > >> > >> >> > [...] >> >> > How would you propose to differentiate between a bugged node and >> >> > a normal node? >> >> >> >> This is why you have authentication and checks against any >> >> inability to connect to nodes. >> > >> > There is no such authentication that would help here. And you would >> > be able to connect to any node normally -- except the compromised >> > nodes would still find a way to become your peers and surround you. >> > (I'm not sure exactly what criteria need to be met for your node to >> > accept a stranger's offer, but I'm sure a dedicated adversary can >> > easily meet them.) >> >> I think you are wrong here. I think authentication could work to a >> degree provided certain conditions are true/consistent enough. I am >> assuming certain things such as there being enough nodes that come >> online daily and stay online permanently. It may not work if the >> number of nodes which come online and then go offline is high. I'm no >> expert here although in theory you should be able to use >> authentication to verify that old nodes are still under the control >> of the person they were under prior. Chances are the initial nodes >> you trust aren't going to be compromised by your adversary. > > First of all, on opennet, the peers you are connected to change every > few minutes/hours. They are not static. They constantly change to make > routing more efficient, via "swapping". I was not suggesting the bad > guys actually compromise other people's nodes -- the far easier and > more likely scenario is they simply have *their own bugged nodes*, and > try to become your peer. (And I think, (not absolutely sure), for a > dedicated attacker, this is pretty easy.) > > >> The adversary would have to slowly bring on new nodes then and would >> be limited to a particular number of nodes per day (however many is >> typical). If they try bringing on too many new nodes at once an alert >> should go up. > > So, again, *their nodes* (just a few... 10-20?) will initiate peering > with your node. And there is nothing you or anyone can do about it. > This is the problem with connecting to strangers -- ie. opennet. > > Although, I guess this can be (already is?) mitigated somewhat if we > only allow a certain percentage of our peers to come from external > (swap, etc) requests -- but then it would simply become a question of > time before you initiate peering with their nodes -- and they will have > many, including big and popular seednodes. > > >> For instance say there are 5000 nodes already, and there are never >> more than 20 new nodes that come on per day then the adversary would >> need 8 months to add 5000 nodes. If they brought on 40 nodes a day it >> would be apparent that an attack was underway. > > How would you tell the difference between freenet becoming more > popular, and the bad guys slowly infiltrating the opennet? Also, you > assume they only have a few days to perform the attack -- how do you > know most of the current nodes aren't "them" right now? You wouldn't know. But you can't exactly be targeted until you exist. Second. There are lots of adversaries. Not all of them are going to be targeting you. If the number of nodes is increasing it makes any one adversaries job all that much harder to target any one particular user. The Tor project has said such before. The more nodes that exist the harder certain attacks are to perform. Many of these attacks become apparent too if done too quickly. I'm not saying this would work for Freenet. I'm just saying it depends on the model and various factors. Freenet is very small. So it Tor. If every computer was distributed with Freenet or Tor many of these attacks would be much more difficult. Your node should have a choice as to who to connect with. If you have enough choice you will be unlikely to come across your adversary given a random selection of nodes. > > >> The way to do this really is to monitor the data and figure out what >> the statistics are or have been over time and then base it off this >> information. If there is a change in those statistics it could >> indicate an attack. > > This is being done. But it won't help in this case at all. (Even if I > wanted to dump thousands of bugged nodes into the network, I could > simply post a Slashdot article, and join that upsurge.) You could. But then that upsurge would probably make it all the more difficult to perform the attack. > > >> >> You are looking at the issue wrong. It doesn't matter which nodes >> >> are bugged. If a user can't connect to higher than normal >> >> percentage of nodes it should send up a red flag for one. >> > >> > They will be able to. >> >> They will be able to what? > > They will be abl
Re: [freenet-support] Freenet speed & local threats
On Sun, 11 Dec 2011 20:05:36 -0500, Chris wrote: > > On Sun, 11 Dec 2011 16:36:53 -0500, Chris wrote: > >> How many users actually compile it themselves? > > > > Me, and all other Gentoo users :-). > > > >> How many examine the diffs? > > > > I do, rarely :s. > > > > > >> > [...] > >> > How would you propose to differentiate between a bugged node and > >> > a normal node? > >> > >> This is why you have authentication and checks against any > >> inability to connect to nodes. > > > > There is no such authentication that would help here. And you would > > be able to connect to any node normally -- except the compromised > > nodes would still find a way to become your peers and surround you. > > (I'm not sure exactly what criteria need to be met for your node to > > accept a stranger's offer, but I'm sure a dedicated adversary can > > easily meet them.) > > I think you are wrong here. I think authentication could work to a > degree provided certain conditions are true/consistent enough. I am > assuming certain things such as there being enough nodes that come > online daily and stay online permanently. It may not work if the > number of nodes which come online and then go offline is high. I'm no > expert here although in theory you should be able to use > authentication to verify that old nodes are still under the control > of the person they were under prior. Chances are the initial nodes > you trust aren't going to be compromised by your adversary. First of all, on opennet, the peers you are connected to change every few minutes/hours. They are not static. They constantly change to make routing more efficient, via "swapping". I was not suggesting the bad guys actually compromise other people's nodes -- the far easier and more likely scenario is they simply have *their own bugged nodes*, and try to become your peer. (And I think, (not absolutely sure), for a dedicated attacker, this is pretty easy.) > The adversary would have to slowly bring on new nodes then and would > be limited to a particular number of nodes per day (however many is > typical). If they try bringing on too many new nodes at once an alert > should go up. So, again, *their nodes* (just a few... 10-20?) will initiate peering with your node. And there is nothing you or anyone can do about it. This is the problem with connecting to strangers -- ie. opennet. Although, I guess this can be (already is?) mitigated somewhat if we only allow a certain percentage of our peers to come from external (swap, etc) requests -- but then it would simply become a question of time before you initiate peering with their nodes -- and they will have many, including big and popular seednodes. > For instance say there are 5000 nodes already, and there are never > more than 20 new nodes that come on per day then the adversary would > need 8 months to add 5000 nodes. If they brought on 40 nodes a day it > would be apparent that an attack was underway. How would you tell the difference between freenet becoming more popular, and the bad guys slowly infiltrating the opennet? Also, you assume they only have a few days to perform the attack -- how do you know most of the current nodes aren't "them" right now? > The way to do this really is to monitor the data and figure out what > the statistics are or have been over time and then base it off this > information. If there is a change in those statistics it could > indicate an attack. This is being done. But it won't help in this case at all. (Even if I wanted to dump thousands of bugged nodes into the network, I could simply post a Slashdot article, and join that upsurge.) > >> You are looking at the issue wrong. It doesn't matter which nodes > >> are bugged. If a user can't connect to higher than normal > >> percentage of nodes it should send up a red flag for one. > > > > They will be able to. > > They will be able to what? They will be able to connect to normal nodes too. Of course, from your perspective, they're *all* equal strangers. (On opennet.) > >> I don't doubt that some developers think opennet mode is hopelessly > >> insecure. > > > > It's not that they "think" it's hopelessly insecure. It really > > is :p. I mean, it might still be "good enough" -- but there are > > actual, well-known, unsolvable problems with the opennet idea. > > Which that FAQ should have explained :p. > > I'm not arguing it is or isn't. Everything is relative though. No, everything is not relative :P. Opennet *is* pretty easily exploitable by design. This isn't a problem with freenet in particular -- but of any untrustworthy network. (Opennet does actually have a minimal amount of trust in it -- via the seednodes. But it's easily exploitable. A darknet is the way to go. (The only reason why the opennet is still around is because people are lazy and complacent.)) > >> I think the best way to organize a revolt or guerrilla war fare in > >> todays world would probably be to anonymously organize multiple > >> small group
Re: [freenet-support] Freenet speed & local threats
> On Sun, 11 Dec 2011 16:36:53 -0500, Chris wrote: >> How many users actually compile it themselves? > > Me, and all other Gentoo users :-). > >> How many examine the diffs? > > I do, rarely :s. > > >> > [...] >> > How would you propose to differentiate between a bugged node and a >> > normal node? >> >> This is why you have authentication and checks against any inability >> to connect to nodes. > > There is no such authentication that would help here. And you would be > able to connect to any node normally -- except the compromised nodes > would still find a way to become your peers and surround you. (I'm not > sure exactly what criteria need to be met for your node to accept > a stranger's offer, but I'm sure a dedicated adversary can easily meet > them.) I think you are wrong here. I think authentication could work to a degree provided certain conditions are true/consistent enough. I am assuming certain things such as there being enough nodes that come online daily and stay online permanently. It may not work if the number of nodes which come online and then go offline is high. I'm no expert here although in theory you should be able to use authentication to verify that old nodes are still under the control of the person they were under prior. Chances are the initial nodes you trust aren't going to be compromised by your adversary. The adversary would have to slowly bring on new nodes then and would be limited to a particular number of nodes per day (however many is typical). If they try bringing on too many new nodes at once an alert should go up. For instance say there are 5000 nodes already, and there are never more than 20 new nodes that come on per day then the adversary would need 8 months to add 5000 nodes. If they brought on 40 nodes a day it would be apparent that an attack was underway. The way to do this really is to monitor the data and figure out what the statistics are or have been over time and then base it off this information. If there is a change in those statistics it could indicate an attack. > >> You are looking at the issue wrong. It doesn't matter which nodes are >> bugged. If a user can't connect to higher than normal percentage of >> nodes it should send up a red flag for one. > > They will be able to. They will be able to what? > >> You can keep track of nodes as well and check out which nodes are new >> and which have been added over time. The number of new nodes coming >> online shouldn't exceed a certain threshold. If there are 5,000 and >> on average the number of nodes increase by 2 a week then 100 new >> nodes coming online should send up a red flag. I don't know what the >> actual numbers are or the range. Maybe some weeks do see 100 nodes >> and others only 2. There is probably a number though that could >> increase the time it takes to pull off such an attack. > > There is no such metric -- a slashdot article, for example, could > easily trigger such a gauge. Moreover, you're not understanding the > attack enough -- the bad guys don't need to control too many bugged > nodes -- just a few which they will find a way to peer with you. > > By the way, here is one freesite that tries to measure how many nodes > are on the network: > > USK@85gZTCiQO9IEPDAGvjktO9d-ZMS1lIABR6JB85m4ens,VGDItiCVzCcWAay51faZzcIfAepzeHpzXYvChlueWYE,AQACAAE/stats/1533/ > > >> >> and if is not made apparent that is a problem with freenet (or >> >> whichever project you would be suggesting). >> > >> > Yes it is. And that's why it's in the FAQ :p. You should take a bit >> > more time, and read it more carefully: >> > >> > "Combined with harvesting and adaptive search attacks, [the >> > bootstrapping attack] explains why opennet is regarded by many >> > core developers as hopelessly insecure. If you want good security >> > you need to connect only to friends." >> >> I don't think you understand how it works that well. I suspect if >> some of your friends are compromised you won't be. > > Did you even read the "Correlation attacks" subsection, from > http://freenetproject.org/faq.html#attack ? Yes. I get the jist of it. > > >> I don't doubt that some developers think opennet mode is hopelessly >> insecure. > > It's not that they "think" it's hopelessly insecure. It really is :p. I > mean, it might still be "good enough" -- but there are actual, > well-known, unsolvable problems with the opennet idea. Which that FAQ > should have explained :p. I'm not arguing it is or isn't. Everything is relative though. > > >> I think the best way to organize a revolt or guerrilla war fare in >> todays world would probably be to anonymously organize multiple small >> groups. > > I strongly disagree. The battle (no matter which one you pick, > probably) is ultimately in the minds of the boring violence-phobic > masses -- the majorities. If you don't have popular support, you're > doomed no matter what you try to do. The best way to organize a revolt > is to talk to your friends and family and convince them
Re: [freenet-support] Freenet speed & local threats
On Sun, 11 Dec 2011 16:36:53 -0500, Chris wrote: > How many users actually compile it themselves? Me, and all other Gentoo users :-). > How many examine the diffs? I do, rarely :s. > > [...] > > How would you propose to differentiate between a bugged node and a > > normal node? > > This is why you have authentication and checks against any inability > to connect to nodes. There is no such authentication that would help here. And you would be able to connect to any node normally -- except the compromised nodes would still find a way to become your peers and surround you. (I'm not sure exactly what criteria need to be met for your node to accept a stranger's offer, but I'm sure a dedicated adversary can easily meet them.) > You are looking at the issue wrong. It doesn't matter which nodes are > bugged. If a user can't connect to higher than normal percentage of > nodes it should send up a red flag for one. They will be able to. > You can keep track of nodes as well and check out which nodes are new > and which have been added over time. The number of new nodes coming > online shouldn't exceed a certain threshold. If there are 5,000 and > on average the number of nodes increase by 2 a week then 100 new > nodes coming online should send up a red flag. I don't know what the > actual numbers are or the range. Maybe some weeks do see 100 nodes > and others only 2. There is probably a number though that could > increase the time it takes to pull off such an attack. There is no such metric -- a slashdot article, for example, could easily trigger such a gauge. Moreover, you're not understanding the attack enough -- the bad guys don't need to control too many bugged nodes -- just a few which they will find a way to peer with you. By the way, here is one freesite that tries to measure how many nodes are on the network: USK@85gZTCiQO9IEPDAGvjktO9d-ZMS1lIABR6JB85m4ens,VGDItiCVzCcWAay51faZzcIfAepzeHpzXYvChlueWYE,AQACAAE/stats/1533/ > >> and if is not made apparent that is a problem with freenet (or > >> whichever project you would be suggesting). > > > > Yes it is. And that's why it's in the FAQ :p. You should take a bit > > more time, and read it more carefully: > > > > "Combined with harvesting and adaptive search attacks, [the > > bootstrapping attack] explains why opennet is regarded by many > > core developers as hopelessly insecure. If you want good security > > you need to connect only to friends." > > I don't think you understand how it works that well. I suspect if > some of your friends are compromised you won't be. Did you even read the "Correlation attacks" subsection, from http://freenetproject.org/faq.html#attack ? > I don't doubt that some developers think opennet mode is hopelessly > insecure. It's not that they "think" it's hopelessly insecure. It really is :p. I mean, it might still be "good enough" -- but there are actual, well-known, unsolvable problems with the opennet idea. Which that FAQ should have explained :p. > I think the best way to organize a revolt or guerrilla war fare in > todays world would probably be to anonymously organize multiple small > groups. I strongly disagree. The battle (no matter which one you pick, probably) is ultimately in the minds of the boring violence-phobic masses -- the majorities. If you don't have popular support, you're doomed no matter what you try to do. The best way to organize a revolt is to talk to your friends and family and convince them peacefully and rationally. (And freenet is a great tool for this! :D.) ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet speed & local threats
> On Sun, 11 Dec 2011 01:04:09 -0500, Chris wrote: >> [...] >> I would put money on them taking advantage of zero day exploits >> and/or the courts to force the Tor project, the Freenet project, the >> i2p project, or any other similar project to modify the code and >> insert a back door. Germany did this many years ago with one project >> and successfully identified a user. It was none of the above projects >> although the ability to force upon developers code changes that go >> out to all users has occurred. They were targeting one individual too >> that appeared to be a fairly low-value target. The only thing that >> might stop this from happening to other projects is where the >> developers are operating in one country and the government attempting >> to force the change is in another. > > Another thing that might stop this from happening is open source > software, and at least a bunch of coders reviewing and signing any code > before it gets released. (I'm actually not sure how many coders have to > currently sign -- surely it's not just Toad?) It mitigates it to a degree although the concern still exists. For a few reasons. The party who distributes the binary is going to be ordered not to reveal the modifications. The main page/download page isn't going to warn users and that is likely the only information they are going to see before updating. It becomes newsworthy information though so there is a slight chance a user who keeps up on this stuff would notice prior to installation. The court could order the source code not be released for the new binary too. At least not the code that matches the new binary. Then users would need to actually notice the binary differs from the source code and disassemble it to find the bug. How many users actually compile it themselves? How many examine the diffs? > > Do you have a link or more info on that German case? Was it open-source > software? Did the developer willingly co-operate, or did they use some > kind of backwards legal mechanism to force him? I wonder how much I can > buy Toad for. Everyone has a price ;-). > JAP. Here is some more info on it: http://smokeys.wordpress.com/tag/java-anonymous-proxy/ This may be the most serious breach I have ever heard of with any software and could potentially threaten other projects. The danger was detected right away as the softwares source code was available. Many users updated and were compromised before they became aware of this though. In this instance they were targeting a particular individual although compromised every user of the service. The individual they caught may not have been the same person they were targeting. This is a risk with mass surveillance/search/DNA... > >> > The whole point of opennet is to be able to connect to anybody you >> > want :P. And if your ISP is compromised, this becomes even more >> > trivial -- they can block all but their own seednodes, so you're >> > forced to only connect to their bugged nodes as peers. >> >> This should become apparent to the user > > How would you propose to differentiate between a bugged node and a > normal node? This is why you have authentication and checks against any inability to connect to nodes. You are looking at the issue wrong. It doesn't matter which nodes are bugged. If a user can't connect to higher than normal percentage of nodes it should send up a red flag for one. You can keep track of nodes as well and check out which nodes are new and which have been added over time. The number of new nodes coming online shouldn't exceed a certain threshold. If there are 5,000 and on average the number of nodes increase by 2 a week then 100 new nodes coming online should send up a red flag. I don't know what the actual numbers are or the range. Maybe some weeks do see 100 nodes and others only 2. There is probably a number though that could increase the time it takes to pull off such an attack. I realize you do not have thousands of peers with freenet. This is just an example of how the difficulty of an attack may be reduced with some designs. > >> and if is not made apparent that is a problem with freenet (or >> whichever project you would be suggesting). > > Yes it is. And that's why it's in the FAQ :p. You should take a bit > more time, and read it more carefully: > > "Combined with harvesting and adaptive search attacks, [the > bootstrapping attack] explains why opennet is regarded by many > core developers as hopelessly insecure. If you want good security you > need to connect only to friends." > I don't think you understand how it works that well. I suspect if some of your friends are compromised you won't be. I'm not reading this bootstrap attack as you understand it. I don't doubt that some developers think opennet mode is hopelessly insecure. > >> > [...] >> > In darknet, you *explicitly* specify who to connect to (hopefully a >> > trusted friend), and you don't connect to anybody else. So, to >> > infiltrate this setup, the ba
Re: [freenet-support] Freenet speed & local threats
On Sun, 11 Dec 2011 01:04:09 -0500, Chris wrote: > [...] > I would put money on them taking advantage of zero day exploits > and/or the courts to force the Tor project, the Freenet project, the > i2p project, or any other similar project to modify the code and > insert a back door. Germany did this many years ago with one project > and successfully identified a user. It was none of the above projects > although the ability to force upon developers code changes that go > out to all users has occurred. They were targeting one individual too > that appeared to be a fairly low-value target. The only thing that > might stop this from happening to other projects is where the > developers are operating in one country and the government attempting > to force the change is in another. Another thing that might stop this from happening is open source software, and at least a bunch of coders reviewing and signing any code before it gets released. (I'm actually not sure how many coders have to currently sign -- surely it's not just Toad?) Do you have a link or more info on that German case? Was it open-source software? Did the developer willingly co-operate, or did they use some kind of backwards legal mechanism to force him? I wonder how much I can buy Toad for. Everyone has a price ;-). > > The whole point of opennet is to be able to connect to anybody you > > want :P. And if your ISP is compromised, this becomes even more > > trivial -- they can block all but their own seednodes, so you're > > forced to only connect to their bugged nodes as peers. > > This should become apparent to the user How would you propose to differentiate between a bugged node and a normal node? > and if is not made apparent that is a problem with freenet (or > whichever project you would be suggesting). Yes it is. And that's why it's in the FAQ :p. You should take a bit more time, and read it more carefully: "Combined with harvesting and adaptive search attacks, [the bootstrapping attack] explains why opennet is regarded by many core developers as hopelessly insecure. If you want good security you need to connect only to friends." > > [...] > > In darknet, you *explicitly* specify who to connect to (hopefully a > > trusted friend), and you don't connect to anybody else. So, to > > infiltrate this setup, the bad guys would have to physically > > compromise your friends' nodes, one by one. To infiltrate opennet, > > they just have to type on a keyboard in the comfort of their homes. > > If you could trust your friends there wouldn't be any need for > freenet. The problem is you can't trust anybody. If you can't trust anybody, then what do you hope to achieve? Who do you hope to communicate with -- if everyone is your enemy? ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
