I see from the past couple of dev updates that NAT traversal is back on the cards again and this is an area of particular interest to me. Has the technique evolved from what was written in the 2010 paper on the subject (I’ve not been able to find more recent documentation) - other than a couple of flow charts.
I actually asked these questions first a couple of years ago but didn’t get an answer to them. I’d be grateful if someone could give me an overview now that it’s looking like things are approaching the final leg before a release.
1: Bootstrapping. I have just got hold of the vault installer. I run it and now the application wants to connect to the SAFE Network. How does it find the SAFE Network?
2: What is the current percentage of routers that your NAT traversal technique is compatible with? What is the general algorithm (if it’s different to the 2010 paper). What steps (if any) are you taking if port forwarding and NAT traversal fail?
There is a separate crate under heavy development at the moment. GitHub - maidsafe-archive/nat_traversal That will give the code. Main updates are recent moves in tcp hole_punch so we are adding that.
Initially there is a cache file of all known nodes (on restart this is used). Initially there will be either locally detectable nodes (we use udp broadcasts), or hard coded seed nodes ( we run these on digital ocean, best but less safe) or indeed a friend can send you known nodes via an out of band method (phone, chat/ mail etc.
1 udp circa 83%
2. Tcp circa 65%
UpNp, Direct connect Nat-Pmp - unknown
Not scientific numbers but none are in the area. These figures are primarily from a recent paper. Consider safe to include/implement a fully decentralised dynamic stun server (but does not use stun per se’ and definitely not ssl/tls as we have routing to transfer public keys for fully encrypted comms). Atm the bootstrap message is plain, but only includes a public key, not a huge issue, but will change when we get an upstream PR for box_seal in Nacl in the sodiumoxide crate.
Hope that helps, in a hangout so forgive typos
If all fails we have manual port mapping and can provide instructions there. This is only an issue for vaults though. We also use a swarm method in routing to bypass some routers where we have 2 nodes each behind a bad router type.
I hope my questions aren’t taken the wrong way, I’m genuinely interested.
I’m probably mistaken but is using TCP support a new thing? I thought you were just using RUDP before? I’m guessing (probably wrongly) that you’re not going to have any long standing connections between nodes. Under what circumstances would I be better opting to use TCP rather than UDP in the context of this network? Does supporting both protocols offer an increased attack surface - i.e. if you’re maintaining two sets of listening code then it’s twice as likely (arguably even more than this) that there’s a bug leading to some exploit (i.e. buffer overflow, etc).
In relation to bootstrapping. Could I offer a friend the IP of a node that’s part of my EVIL Network, where all nodes on EVIL network are identical to nodes on the legitimate SAFE Network and they will then join this none the wiser? Same goes for if I compromise one of your bootstrapping servers? Once I’ve got a load of nodes in my EVIL Network could I then work on a way to exploit some theoretical weakness (which there is bound to be) and monitor all data within the network?
How are updates rolled out? Can a V1 node live in a network where all other nodes are V2? If it can’t how can that node get back onto the network?
“A botnet or other group of malicious Vaults would require to make up around 75% of the whole SAFE Network to achieve false quorum over invalid requests, making a successful attack of this type very unlikely.”
So it’s going to take a lot for you to have an “EVIL Network”.
What I’m talking about is a little different to this. I’m not saying I want to take control of the SAFE Network. I’m saying I want to have a totally alternate network and trick you onto this rather than the official SAFE Network. Obviously I don’t want to do this personally
From day one I can control the size of this network, spawning other networks if I want to keep the percentage of nodes I own high. I can probably also keep you from receiving official vault software updates and this will give me scope to work out how to compromise a particular version of the software and I can then control your node.
The critical bit is: how do you know after you’ve installed your vault that you’re connecting to the real SAFE Network? How can you trust the source that’s saying “welcome to the SAFE Network, in order to join connect to node 85.10.10.5”. Is the source lying and actually putting you into an network controlled by North Korea?
Your data/login etc. would need to be in the North Korea network :D. Of course there is way more to this than meets the eye and will have interesting discussions after launch. There can be segmented networks (We do it all the time in testing). Structured data logins/safecoin/dns etc. all need to be available or you asa client know you are on wrong network. Other things like network density changes etc. also help you, but overarching is all your stuff need to be found there and then the folk you speak with etc .
So lots to discuss and much of it valid.
In the other things you mention there are very long discussions/answers and I am not evading but flat out so some bullets (forgive brevity)
Network will use tcp udt (like rudp) and other protocols on v4 and v6 addresses on random ports and with network layer authenticated encryption. The underlying protocol will carry the layer 3 data and not much more so attack vector, I am not seeing that, but taking many routes over different protocols is arguable going to make detection much harder.
Of course you can get a friend to bootstrap to your network, evil or not Nodes on the network do not decrypt data and cannot, only client side can so you would be as well asking the real network for all the data (it will give it to you if you ask) and try to decrypt that and put it back into order etc., Seeing the data en route or at rest makes little difference in terms of decryption. It was a big issue we decided on, do not rely on secrecy of network or storage places, make it all open and instead secure the actual data itself. Then we do not need vpn’s intrusion detection firewalls and all the stuff we bundle on insecure data and storage that we have today. So the crux is secure the data not the server as the server is never gonna be secure. The network however, is another security, the security of action, i.e. doing the right thing. This all makes the attack vectors at least a bit different for sure.
Thanks for taking the time to reply again, I appreciate you’re a busy man!
I’m afraid I’m struggling to see though how a client would know they’re not on the real SAFE network if they’ve never been on it before. If I compromise the bootstrapping server(s) then new clients are never going to get into SAFE and they’ll create their accounts within the network I direct them towards. Maybe I’m missing something - is the account actually created before the user installs the vault software? If this is the case then I’m going to have to connect to some server using current technologies to do this - and if I can compromise the bootstrapping server I could also compromise the signup one.
I totally get that I can’t do anything with the data alone and that nodes are just relying stuff. I suppose what I’m getting at is; if I can get you to come into a network that I have a certain amount of control over (and you’ve not been on the SAFE network previously) then I can work on a way to compromise your vault and get your keys. I can control the number of new nodes that enter this network (because I control the bootstrapping server I can send the first 100 new nodes to network A, second 100 to network B, etc.) and my nodes will tell you that everything is A-OK. Also, if vaults can be updated over the network then I should be able to work out how to get it to download my update (all my nodes will be saying it’s legit) and get your node to send me your credentials/keys/whatever.
Imagine the same process but replace SAFE with facebook, twitter, bitcoin etc. It is really that straightforward. If you were previously on SAFE then it’s even simpler really.
Your vault does no have your keys. It creates session keys as does CRUST (the network layer) and the routing layer. Client keys are retrieved by the client from the (real) network.
All you would get is either encrypted data or signed updates to data (this could be where you can do something by ignoring the update to SD, but you need to have got the original one). So you could at very great cost do a DOS Attack on a user (perhaps). Not simple, say you were paying somebody a safecoin - they would not get it so again you should know. This also assumes you control all the bootstrap nodes the client connects to.
Hope that helps - sorry again for brevity. I really need to get back to code, but will try later to help out if I can, just really lacking sleep these days (check my github, it’s pretty manic).
Thanks again. Apologies for still banging on about this…I’m not intentionally trying to be a PITA it’s just I’m not sure if we’re speaking about different things.
Of course there’s no rush to reply
I guess where I see the difference is that it’s going to be easier to compromise your bootstrapping server(s) (the Digital Ocean ones that get you onto the network for the 1st time) than it is to compromise the likes of Facebook, purely because they have a great deal more resources to throw at protecting their servers than you do. Even then they’re not immune (think Garry McKinnon and US Military, NASA, etc. etc.)
If I only wanted to deny the user of some service (I’m getting from the context this is what you mean rather than trying to flood the user with rubbish) then because they are on a network where I can control the majority of nodes then I could quite easily stop them from getting things.
I’m not sure if I’ve got the wrong end of the stick or if things are getting lost in translation because of terminology differences. I’m talking about controlling the servers you said you have hosted by Digital Ocean. I’m not interested in trying to do anything with nodes that are already in the SAFE network. I just want to poach new ones before they get to it.
I’ll try and take a look at the update side of things when I get some time - it’s an interesting problem. At the minute the only way I can make sense of what you’ve said is by thinking there’s a version of each update for each vault within the network but encrypted with the users key. If this were the case then I agree that I couldn’t compromise a node by putting out a dodgy update (even if I controlled the network). I can’t see how you could do this though - because you’d have to have knowledge of the client somewhere in order to encrypt the update specifically for them.
I thought it would help if I outlined how I think an attack could work and this will hopefully clear up any ambiguities that there might currently be.
I compromise the Digital Ocean servers used during the bootstrapping process of new nodes - perhaps I’m even a government that has decided the network is illegal and I force Digital Ocean grant me full access. In any case I can now redirect people who think they are creating a new account on SAFE through to my network (which looks just like SAFE but isn’t).
I’m going to keep things simple to help with readability by assuming new users sign up infrequently. If this is the case then I can probably acheive what I want if I just have 2 networks that look like SAFE and they wouldn’t be expensive. If users are signing up more quickly then I’ll need more networks (but let’s keep things simple ;))
The 1st of my networks is a landing point for new users and the 2nd is where I pass users once I’ve compromised them.
The 1st network is full of nodes that I own outright (i.e. they’re running on my machines) and I don’t have to have many - the fewer the better actually. The Digital Ocean bootstrapping server forwards a new user into this network and the user creates an account (obviously in this network). Because I own all other machines I can tell what files of theirs entered the network and I can now move these files into my second network - which I beleive would migrate their account? Because I know this new nodes IP address (they’re the only foreign node in my network and will have a direct connection to at least some of my nodes) I can work on compromising their machine.
Once I have compromised their machine I push this user over to my second network (probably lots of ways I could do this, like making sure when their node restarts - and they bootstrap off my 1st network - that their introduced to nodes in my 2nd network).
This 2nd network is full of machines that I don’t physical own but I do virtually, i.e. I’ve compromised them all. I obviously make the rules here and can do whatever I want; monitor them, use them for DDoS attacks, etc. etc.
Interesting exchange. I can only assume you may have a skillset or two that could somehow/someway short/long term compliment David & Team. There are never too many “smartest guys in the room”.
Yes, with several caveats (I am extremely short of time)
As if you poisoned a DNS And a user thought they were logging into facebook or twitter etc. for the first time and you create the same universe they expect. This is similar I think to what you are saying.
If the only way to start on the network was open digital ocean machines (which it is not), then this kind of attack would catch new users and put them on a network you create, There would not be tradable safecoins or many usable data bits etc. though (of course unless you route them to the real network).
So basically if we said we have a new crypto currency with 2 seed nodes on DO (as many do) and you broke into that and took control it would be the same. I think this is the kind of thing you are talking off, or am I not seeing the issue?
I can help a bit more if this is the case, otherwise I can take a peek later. We are in a google hangout so I am live coding while trying to answer this, so brevity again
Thanks David, I’m happy we’re on the same page now
This is exactly what I’m saying. The difference though is that there would be more motivation to want to do this with SAFE than the likes of FB (especially since the vast majority of the data on the likes of FB is all too public!). The CIA, etc. will also have other avenues into FB. Also a criminal is likely to find information that’s much more valuable in something like SAFE than on FB because people are trusting that they are protected.
I appreciate that the alternative is a “by invite” model. This isn’t going to let the network grow particularly quickly though and who knows if the person who’s inviting you isn’t on a compromised network already?
I can’t really comment on the SAFE Coin stuff - this side of things doesn’t really interest me and I haven’t looked into it. I think though in my 2nd network there could be plenty of data. I set the rules (as I can update the nodes) so I can allow people to store data without using SAFE Coin and there would then be plenty of data in the network. I guess if the network attracts Joe Public then he’s not going to be any the wiser because cypto-currencies are going to be even less interesting to him than they are me.
I’m obviously glossing over all the reasons why you want a currency in the network and this could well lead to problems. I’ve spent 0 time thinking about this though but I recon since I’m capturing all users at the point of account creation I’d be able to do something that’s at least capable of keeping most users in the dark.
@BIGbtc Thanks for the flattering comment but I can’t see it happening I’m afraid. I am honestly very interested in the technology but I have a very different opinion on how it should be used - I won’t pollute this thread by going into the reasons
And this one as well, although it’s not 100% correct anymore:
The thing is, you can’t choose your own XOR-address. The network gives you one when you connect. And when you connect on IP-level it’s through relay-nodes. So when you connect to 4 ip-addresses (relay-nodes) 1 could trick you to a different network, but you interact over 4 relay-nodes, so your node would find out soon that 1 is corrupt.
When the network goes live, you connect to it using a build-in PKI to one of the Maidsafe-servers. And they’ll provide you with different IP’s and will try to get rid of you as fast as they can I predict . From that moment your client knows about maybe 10 or 20 IP’s so when you ever connect again you don’t use fallbacknodes from Maidsafe but just try to pick some you already know. And when you’re connected to the network through one of them, they don’t have a clue what you are doing. They’ll just route your data back an forth.
Thanks for taking the time to dig out those posts.
For this attack to work it doesn’t actually matter how good the security is within the SAFE Network. It could be like Fort-Knox on PCP but it doesn’t matter because you (as a new user) are never going to get into the SAFE Network because I’ve compromised the Maidsafe servers and rather than them shunting you off to the SAFE Network they are going to pass you through to mine.
As mentioned above I can then go on to do interesting things like isolate your account, determine your IP address (1st step to compromising your machine and/or identifying you), move you to other networks, etc. If I wanted to I could also control the percentage of machines that I own on my networks - branching off other networks if I want to re-balance things in my favor and I could probably move your files with you (assuming I’ve compromised your machine).
This is a very extreme case, it probably is possible what you describe. But how big is the chance that some agency/government will hack Maidsafe (the company) it’s hardware? I think it’s not that big. My view is that the Devs will run a number of nodes to start the network. Say some are on Amazon AWS, some are in Troon, some other nodes on a different continent as well. Then David and some of the other Devs will connect from their homes to try it out as well. And when they have a little network up and running (that is on different systems and OS) and things work well, they share the installers for us all. So for someone to hack the thing out of this, you’ll need a lot of hardware hacking.
Within a few days we’ll have at least 1000 people joining the network. People upload some files, others some Safe-websites. So if you want to trick new users into a different network you would at least need to copy all this stuff as well. otherwise people notice that website safe:ABC doesn’t work for all users, and that would show a fault in the network.
Another example using your example is Bitcoin. My node at home connects to 8 IP’s all in plain text. There are some fallback servers for that network (no encrypted communication) as well.
I was not really referring to invite only. What I mean is we have
Seed nodes (these will not be on a single provider or location at launch)
LAN beacon
Pass a bootstrap file between people
Gossip (in planning)
There is also btc like dns seeding but I am not so keen on that. We will be playing around though.
What I meant more so is that, say you figured a new user could be grabbed by X (X == take control of his seed nodes as an example). Then if that person were to join and speak to others, trade, share files etc. you would need to provide that universe for that person. Video chat with pals etc.
So you could route real stuff to real places, but there is a problem. These are authenticated encryption, so what do you route and what do you try and fake?
Then after that how do you make sure they never connect to the real network?
Would an easier version of this attack not be to just code a completely new binary and let them download that, making it easier to emultate the expectations of the client software?
If you prevent a vault is will be almost meaningless as it has nothing and only gains form doing stuff for the real network. This is the DOS attack I mean, you can deny a person farming with a vault if you managed to take over the right number of seeding places the vault chose to use. Then you can prevent somebody who never farmed from farming and that would be DOS.
In terms of clients I feel the issues over joining a new facebook with none of yer pals on it or twitter with none of your friends may be apparent quickly.
Imagine for instance you did this to skype when it was p2p? Folk would realise pretty quickly something was wrong. I wonder if anyone tried, the seed nodes were right there in the skype config file (several publicly facing bsd nodes IIRC). It is a similar issue I think and would have a similar consequence. Of course the best is we never have seed nodes or need them and this is I believe entirely possible with aggressive node finding techniques and more so when the network scales out.
Hangout over so had a few mins this time to answer
One idea might be to bundle public validation keys with the bootstrap public keys. If the bootstrap node is compromised and sends you to a false network, it would be impossible for the attacker to sign the validation keys with the developers’ private validation keys. The attacker would have no way of finding, compromising, and stealing these keys as they are stored on the network which affords all of it’s protections. The attacker would have force or coerce the entire developer pool into giving their private validation keys up.
Example:
Attacker compromises a bootstrap node be it hosted by Maidsafe or a network peer (as David intends it to eventually be).
The attacker now has access to the private key of the bootstrap node.
Clients connect to the malicious bootstrap node.
The malicious node redirects the client to the fake network.
The client requests that the validation keys be signed by the developers private keys stored on the network.
Since the attacker and his/her network does not and cannot know the private keys, the client rejects the network and informs the user of the potential attack.
Problem solved.
On the real SAFE network, the client would have at least >50% of the validation keys signed thus validating that it is on the true SAFE network.
Out of these options though only 1 and 3 are applicable when talking about connecting to the network initially - no? In both of these cases I’ve got to trust the source. One of the fundamental problems you’re trying to solve with the network is that you can’t always trust servers - yet I’m going to have to trust one here ultimately. Even if I get bootstrapping details from a friend he has had to put his trust in either a server or one of his friends, etc. Somewhere along that line a server will most likely be required - which I’d actually probably be more happy to trust than my friends, friends, friend, …
Long and short is no matter how great the security within the SAFE Network is I’ve got a problem before I connect to it. This in itself could be a big problem for some people. Say, you live within some repressive society and the SAFE Network has been outlawed. There’s a real risk that you get caught because of this insecure initial step.
I don’t think it matters too much that there is more than one provider for these hosted seed nodes. In the grand scheme of things there aren’t that many ISP’s - especially somewhere like North Korea I guess! If I’m a government I go to the ISP’s and have them redirect stuff that goes to any of your servers to me.
Indeed. Ideally I’d want to attack early and try and take everyone. This way nobody would be any the wiser.
I’m also wondering if there would be a way for me to mirror accounts in the real SAFE Network. Basically I’ve compromised a node in my network and I can know whatever I want about them (I can capture their credentials, etc.). I build into my version of the network a bridge between it and SAFE so that when a compromised node on my network does something the operation is mirrored on SAFE. So really the user has got two accounts but they are only in direct control of the account in my network - I handle the movement of data between my network and SAFE.
How do I get their credentials? Will probably be lots of ways. A fairly crude way would be to crash their node once I’ve compromised it (on my 1st network) and they will be forced to login again, at which point I capture their details.
Yes and no. If I could have a reliable way to ensure that everyone downloaded my binary then of course this would be easier as it would mean I don’t need the 1st network. This obviously wouldn’t catch cases where people are sharing legitimate binaries though. Even if I was in cahoots with an ISP I can’t stop your friend handing you a disk.
The aim isn’t to hijack individual accounts, it’s to get as many as possible (at least in a particular region, say North Korea). There will be plenty of opportunities and you’ll see most of your pals. If you don’t see some pals then how can you prove it’s not them that’s actually in the fake network? If the bridge I mentioned above can be pulled off then there obviously won’t be this concern.
@Tonda This would help however I don’t think it would be enough. If I’ve understood your plan I think I could find this information out myself, since I can connect to the real SAFE Network and bootstrapping nodes and see what legitimate clients will expect to hear. Could I then just pass this back to clients that enter my network?
Nodes on the network do not decrypt data and cannot, only client side can so you would be as well asking the real network for all the data (it will give it to you if you ask) and try to decrypt that and put it back into order etc., Seeing the data en route or at rest makes little difference in terms of decryption. It was a big issue we decided on, do not rely on secrecy of network or storage places, make it all open and instead secure the actual data itself. Then we do not need vpn’s intrusion detection firewalls and all the stuff we bundle on insecure data and storage that we have today. So the crux is secure the data not the server as the server is never gonna be secure. The network however, is another security, the security of action, i.e. doing the right thing. This all makes the attack vectors at least a bit different for sure.
. From that moment your client knows about maybe 10 or 20 IP’s so when you ever connect again you don’t use fallbacknodes from Maidsafe but just try to pick some you already know. And when you’re connected to the network through one of them, they don’t have a clue what you are doing. They’ll just route your data back an forth.