NAT Traversal & Bootstrapping

Development
102

God help me. I know it’s a flaw in my personality that I can’t let things go. There is still a mass of confusion over what I’m saying and it’s bugging the hell out of me. If I fail to get my point across this time then I’m just going to have to accept that I’ve failed - my dead horse is truly pulverised.

Accepted (or at least these points were accepted by you at some point!)

  • Nodes can identify the other nodes that are directly connected to them (by IP address). This can be used (with the help of ISP’s) to identify the owner.

  • It is possible for an ISP to get between a new user and all bootstrapping nodes that the ISP knows about.

  • It is possible for an ISP to know all users who are requesting a connection to a bootstrapping node that it knows about.

  • It is possible for someone (e.g. an ISP, agency, group, etc.) to create a FAKE-SAFE network which is running customised nodes. This means a new node that enters this network is only talking to fake nodes and is therefore open to a Sybil attack.

  • It is possible for an ISP to to capture and relay traffic between a node and it’s intended bootstrapping node - meaning the fact that the node knows the bootstrapping nodes public key isn’t important because they will be speaking to the correct bootstrapping node (to start with) via the ISP’s “man in the middle”. And this is how the “Man in the Middle Attack” occurs. The middle man can make the node think they are connecting to the correct bootstrapping node. It can then trick it into it’s FAKE-SAFE network where it’s subject to Sybil.

  • It is possible in a quiet network (I think in busy too but I’m limiting things part to what we currently agree on) for ISP’s in cooperation to determine the route of traffic. It is therefore possible for them to pull a file (which may be illegal) and see vaults and relays used to distribute the file. Likewise they can put a file into the network and determine the route it takes - it may of course move after this but at least one copy can always be found by requesting it again.

  • If your node can be identified as transmitting illegal data then it is POSSIBLE for you to be prosecuted (maybe unlikely in most countries but as you said yourself it has happened with Tor in Germany I think). This could happen even if you just happened to be a node next to mine in my jurisdiction and I pull an illegal file - I can prove that part/all of it came through your machine - even if you no longer have a copy.

Disputed (which I happen to think are probable)

  • Once a node is Sybilled it’s very likely it can be tricked into doing something that will compromise it, e.g. download an update.

  • After a node is compromised (or not) it will be possible to release it into the real SAFE network and the owner of the node will very likely not have a clue what happened (the FAKE SAFE network will have created the users account in the real network for them - multiple ways to do this I’m sure - especially easy if the node is compromised).

  • You won’t have to get too many ISP’s on board for them to be able to do a lot of damage. The majority of people will be going through a small number of ISP’s. If you can’t get a complete overview of the route of a file because ISP X isn’t on board you just keep looking until you get routes that are completely within the networks of the major ISP’s.

  • Even if the network is busy it is far from impossible (with the help of ISP’s) to determine the route of data in the network.

  • If you know what you are looking for then it’s possible to follow the route of individual files. At the very least if I have sufficient ISP records and I request a file I will be able to determine the route that the chunk(s) took to get to me.

  • There will be patterns that allow for the analysis of public files on the network (obviously with sufficient ISP records). You could probably work out popular files, where they are being cached, etc. I’ve covered this in a bit more detail earlier.

OK, I’m proposing 2 (I’ll say it again TWO) INDEPENDENT methods for working around the security features of SAFE. The FAKE network is ONE way - if most nodes were compromised then there’s little value in monitoring the network. If nodes CAN’T be compromised then it will be possible to monitor the network to some degree (you think with low accuracy and I think with reasonably good accuracy - enough to warrant further targeted investigation at least).

I’m sure there are other things too that I’ve forgotten or not even considered. I’ve attached a diagram that outlines why I’ve got a reasonable level of confidence why it will be possible to determine the route of files even in a busy network. Of course there’s going to be a hell of a lot of data to sift through. Expensive - yes. Impossible - no. Are there motivated groups with a lot of money that would like the information - of course. Will this be done - nobody knows.

Signing off - again :wink:

1089×1022 44.2 KB

103

Woow, that’s a lot of work you’ve put in it. Respect for that. But I keep saying:

yes, they can block the outgoing connection to these bootstraps. But they can’t man-in-the-middle them or send the clients to a fake-network. In the binaries, that little quite .exe-file on your computer, the public key from the Maidsafe-bootstraps are hardcoded in. So from bit 1, only the bootstraps will understand what’s going on. No person can get in the middle of that. No one. David pointed out here.

and further on:

So there goes you Fake-SAFE-network. It can’t be done on IP-level. So, to begin attacking, you need at least go to the second encryption level. That’s in XOR where you don’t know a person’s IP. Wel, you know the IP and XOR address of your relay-node. But not from your close nodes in XOR.

104

I’m sorry but I think you are misinterpreting David’s comments. Firstly he says all MESSAGES from MESSAGE 1 are encrypted, not everything from BIT 1. In fairness the statement is a bit vague but it is impossible to encrypt everything from bit 1.

Every time you send data from your computer to another over the Internet (or through SAFE which is operating over the Internet) it’s routed through a heap of routers on the way:

Your PC → Your Router(s) → Your ISP ----> Backbone Routers, etc. —> Dest ISP → Dest Router(s) → Dest PC.

It wouldn’t be uncommon for there to be more than 20 hops between your computer and the destination. Each one of these routers on the way needs to know how to route your packets. If your headers are encrypted then they’re not going to be able to work out what to do with them…you’re local network stack probably wouldn’t even allow you to attempt to put something like this into any network - because it wouldn’t understand it. The Crust video you pointed me to should confirm this for you.

Also if you’ve got a packet sniffer (WireShark is a good one if you’re interested) you’ll be able to confirm this by looking at HTTPS traffic. As the protocol name suggests it’s above TCP and do TCP and below is not encrypted.

I think I’ve demonstrated how “Man in the Middle” is possible. If I can capture your packets (which an ISP definitely can) then I can forward your request onto the legitimate bootstrapping server. They will answer the question your asking (because they can decrypt it) and pass the answer back to me. I then send it through to you and you start trusting me.

105

Most of this is over my head, admittedly. But I think the point is that, while the headers to route the message to the bootstrap node must, of course, be readable for routing, the SAFE Network connection data CAN be encrypted from bit 1. The connecting node has the public address of the bootstrap node. Use it to encrypt its own “public key” (only “public” to the node being encrypted to) which only the bootstrap node can decrypt. This prevents anyone else along the way from getting in the middle of the meaningful exchange. Yes, there may be routing points “in the middle”, but no way to impersonate the connecting node, so not true “man in the middle” attack.

2 Likes
106

Nope, again not possible :grin:. I agree you need some header-data that all routers etc. can use to pass the message. But when it comes to Safenet, all is encrypted from bit one. So it might look like this:

Header which says > pass this “block of data” to 11.22.33.44.55.66 using TCP on port:8899

Now this “block off data” is fully encrypted, although the rest is open for all. In the encrypted block is your personal key. And you’ve encrypted using the public key from the maidsafe-bootstrap (in your client). So the only one that can decrypt your message (block of data) is Maidsafe. And when they reply to you they use something like:

Header which says > pass this “block of data” to 66.43.22.77.88.66 using TCP on port:8899

and in their block of data, which is encrypted to you they might say: “successful handshake” but the only 2 nodes that know this info are you and Maidsafe. You’ve created a encrypted communication line. And see how the data in the first block is already encrypted. How would you man-in-the-middle this one? Ohw and btw, David also says you can’t do a MITM on this one. It just isn’t possible.

Yes, you can get in between us! But that’s not a MITM attack, that’s just being a “proxy” which only gives you the power to stop the communication or not. You have no clue what anyone is doing on Safenet. I have the same power over you as well. I can get between your house and the power-supply. When I don’t like you, I can cut off your power. Boom, all your power is gone, you can’t connect to Safenet! But I have no clue what you were doing online.

3 Likes
107

I’m sorry but this isn’t true. As a proxy I’ve got the power to make my own decisions if I want. Think of port forwarding on your router…you tell it if a request comes in on port 8765 then route it through to port 75 on local IP 192.168.0.1. The router isn’t stopping the communication, it’s redirecting it.

Now I’m an ISP in the middle of your node and a bootstrapping node. I can route what I want where I want and I can make you think I’m the bootstrapping node. I might not be able to decrypt anything but I don’t have to. I can route your requests through to the real bootstrapping node and let it handle this and then I feed this back to you.

This allows me to do more than just see a stream of nonsense flowing through my router. It allows me to trick your node into trusting that I’m the real bootstrapping node. This then allows me to move you into my own FAKE-SAFE network where you are subject to a Sybil attack because I own all other nodes. What I’m saying is that I will very likely be able to then trick you into doing something else that will compromise your node - like get you to download an update but there are likely other things that can be done too.

Let’s think through the scenario of you downloading an update that compromises your node. How can you prevent this? One way would be to make sure that you don’t accept updates the first time you’re ever trying to connect to the network. This would prevent the attack as I’ve described it because I’m catching people the first time they connect to a public bootstrapping server. What do I do? I start keeping nodes in my network for a bit longer and have a bridge into the real SAFE network that allows you to keep working as if you were really in it - in a sense you are but you’re route to the real network is through me and you are subject to a Sybil attack whenever I want because I can close the bridge.

As I’ve said before it’s a cat and mouse game. It all boils down in the end though to the fact that the ISP is your god.

So this is an attack - MiM + Sybil

There are also other monitoring options as I’ve outlined so this attack isn’t the only thing to worry about. Plus CIA, NSA, etc. are going to have loads of people much brighter than me with a crazy amount of resources.

108

Look even if you are right (and there is more then one objection to what you say) you are only suggesting that if a totalitarian government is out to get you they might succeed, that means absolutely nothing to this project.

The purpose of this project is to end MASS surveillance, it’s to end dragnet type surveillance, it’s to end hackers easily compromising any and all private info that they wish.

What you have successfully done is fallen into the contrarian trap of being right about a fringe case that means nothing to the project but proves to yourself that you are smart. That is a trap that many have fallen into with many technological projects. Prime example being Bitcoin (because it is closest to us), the sheer number of very intelligent naysayers is just staggering from Bill Gates and Warren Buffer to the creator of BitTorrent and even some people who now work on Bitcoin core. Not to mention the amount of times Bitcoin has died…

2 Likes
109

No, you can’t do this because you don’t have the keys to communicate on the SAFE level. Remember that communication between client and bootstrap node is end-to-end encrypted, both ways. Client knows bootstrap public key from the start, it uses it to encrypt it’s first message which includes the client’s public key. Bootstrap node’s reply will be encrypted with that client’s public key and will also be signed with it’s own private key. You know neither the client’s nor the bootstrap node’s private key, so you can’t read or do anything above the transport layer (TCP/UDP).

The client will only trust messages from the bootstrap node that are signed with the bootstrap node’s private key, and you don’t have it.

3 Likes
110

You would need him. He would have to rearrange the nature of our current technical reality to make most of what you say is true. If he does come to your aid, please ask him to at least first grant us all equal access to the basic necessities of life. :innocent:

If we were making progress I’d be happy to continue this excruciating discussion. Instead you repeat the same false notions of vulnerability. There are only two things I can give you.

Acknowledgement of this:

They are the Internet service provider after all. They own the wires that carry all of your packets. This does NOT grant them unlimited power. They can only see something is going here and something is going there. That’s it.

Your final gift:

Correction. This is most likely the only way it could happen.

Now that you have been showered with gifts :stuck_out_tongue_winking_eye: I must sadden you yet again with reality. :disappointed:

So what? Everyone is connected to each other via IP. What difference does it make? Identify the owner of what? I hope you’re not suggesting that they can Identify the owner of the questionable material just from the flow of packets? We went over this already.

This a ridiculous and unlikely scenario. Why even entertain it?

The analysis program outputs a probability value directly correlated with the current size of the network. It informs the owner of the tool that too many packet flow synchronizations have occurred to be certain of of the path and origin. As the network grows it begins outputting ever decreasing probability values. This is the likely scenario.

Where they’re being cached? Popularity? Are you kidding me? Caches fall out or move rapidly. Popularity can only be determined by download speeds. You can’t just watch the flow matrix and pick it out. There are no external identifiers. Period. Statistical analysis is highly limited.

Once a lawyer destroys this with the plausible deniability argument, investigators will hesitate to waste precious resources to pursue cases they aren’t certain they could successfully prosecute. So this one gets a maybe in the short term, but in the long term someone is bound to step up and hit a home run. It’s an easy ball to hit. The size of a beach ball, hollow, and little air resistance.

The diagram was a sad waste of your time. It could have been better spent doing research on the matter.

Dude the response given by the true bootstrap node is basically the rendezvous information of the relay node. Since you can’t decrypt the client request or the real bootstrap nodes’ response, you cannot force anyone into your fake network. What about that don’t you understand!!!

I’m slowly losing the will to keep typing for this thread. As slow as I type, I’ll be down to 1 character a second. Come to think of it you would like that wouldn’t you? :expressionless:

1 Like
111

Thank you! :laughing: I laid this out several times as well.

112

Finally…something I can work with! Even if it does require a bit of interpretation

Why could nobody have just said something like this?

The bootstrap node response to a new node is connection details for a collection of relay nodes along with each of their PK’s

Seriously, you can be as arsey as you want but if you don’t give clear information it’s not going to make any sense. Trying to ridicule me isn’t going to somehow answer any questions!

I don’t know what I’m supposed to do when I’m being pointed towards 2 sets of “official” documentation and they both say different things (one says PK’s are exchanged the other says the client knows PK’s beforehand). I accept that you will say “but we told you 100 times” however what I was being told made no sense - everything is encrypted from bit 1, there are only 4 connections into the network, XOR stuff that was irrelevant, no mention of the bootstrapper passing relays PK’s, etc. For all I knew the bootstrapper was just saying go to this IP address - whether or not that was encrypted would make no difference. With the information at hand how could I formulate different ideas to what I did? Even though I’ve put a question mark there I’m not searching for another smart ass comment Tonda.

OK, I see now how Man in the Middle is very unlikely unless the middle man can access the actual bootstrapping node and determine it’s private key.

I’ve not seen anything that convinces me that monitoring is out of the question for a collection of ISP’s. We’re just going to have to agree to disagree on this.

I still can’t see how caching can work with the level of encryption that is being claimed, i.e. all public data is encrypted with the requesters PK. Unless there’s a real official document I would prefer not to get into it.

Thank you

2 Likes
113

You only need to bootstrap here, then you can connect to known nodes you receive via that encrypted data you “forward” so the connection drops and the real connection is established. Therefor you lose the ability to MiTM. All data to the new node is authenticated encryption and with a known good node(s) on the network. So Denial of service is what you are talking about not MiTM. IF your ISP simply cut off your internet then it’s the same thing you are proposing here. I don’t see why you are very keen to state a MiTM attack or sybil attack when it’s not. At most this is DOS attach and of course if there is a single route to the internet then it can be cut off. I don’t see what you are getting at here, sorry if I am missing something, but it seems an encrypted stream that is authenticated must, by definition be MiTM resistent unless you have managed to crack the encryption.

As I said earlier it is good to check, but if we are probing these attacks and I say OK lets assume X it does not mean I think X is possible or agreed to be possible :wink: These are ways to look at security, like imagine I can read you mind and get your password. It does not mean I belive I can read your mind, so please be careful stating I agree to an attack. If I am agreeing to a supposition it is an entirely different proposition and mis quoting me would mean the results are called into extreme question of such an exploration in security of any system.

So with authenticated encryption and assuming that is secure (need to have that conversation with D Bernstein and co in that case) then this is not a MiTM attack AFAIK,. Otherwise it is playing with semantics, I am in the middle and I can reroute your traffic != I am in the middle and can inject/replay etc. These are seen as different attacks and we should not confuse these based on semantics.

Hope that helps.

5 Likes
114

I think this may refer to

  1. Bootstrap connections == client knows public_key beforehand
  2. Rendezvous connections (node to node) then keys are exchanged via the xor network.

Can you provide the links so we can clear that up as it would sound confusing indeed. Thanks for finding it out.

4 Likes
115

If it’s immutable data, the only transit encryption is as it is passed node to node. The storage node encrypts to its close node. The receiving node decrypts, checks and caches, reencrypts with its creds to pass it on to next node. Repeat as needed. AFAIK such data would not be encrypted with the requestor’s PK. The chunk is being returned to an XOR address of the requestor only.

2 Likes
116

Cool. Thanks for the reply. All makes sense with the context I now have.

Here’s link to the most detailed bootstrapping description I could find:

The other link is here:

https://safenetwork.wiki/en/FAQ#Can_an_ISP_thwart_the_network.3F

As far as misquoting you goes. I’m sorry if this happened however I wouldn’t have believed I was at the time. I remember saying you agreed however can’t remember at which point. If it was a genuine misquote then it must have been after I moved off the idea of compromising servers and having ISP’s catching traffic. As you will have seen until very recently I didn’t realise bootstrapping nodes were passing relays PK’s back to the client and therefore assumed that both proposals were close to equivalent. Again, my apologies.

3 Likes
117

Awesome! Thank you for stepping in.

Indeed.

Why could you not have done a very quick google search. It amazes me that you would join an anonymity and security related forum without having been exposed to and studied the current systems. Tor, I2P, Freenet, etc, all use similar bootstrapping methods. With your level of knowledge of general computing, networking and server management I find it hard to believe that you overlooked this. Have you never used Tor? If so, wouldn’t you want to know how it works before putting any trust in it?

It’s true I made some initial assumptions which is why I didn’t see it necessary to spoon feed you the fundamentals. Most would find that condescending. So I gave you the benefit of doubt and it backfired. Forgive me.

Agreed. Remember, I said it would be very difficult not impossible.

The data is not stored on the network with a users PK. Each chunk is encrypted using the the hash of its related chunks as entropy (basically informational noise). This is termed self encryption. It is only when the chunks are requested that the users public key is used to encrypt (wrap it in another layer) the data for transport. As I said before, if the relay node becomes (will likely be) a problem for public data (i.e. the fingerprint attack I wrote of before), the data managers, close groups or both could add random bits to alter the fingerprint during transport.

Again @dirvine , I’m very sorry to interrupt your work but could you please inform me if it is indeed possible to do what I claim is possible.

This is the fingerprint attack I speak of:

This the idea Post 56:

Can it be done? Is it flawed?

118

Told you 100 times ;-). No just kidding, I get what you didn’t get. It is quite amazing stuff actually. When I said that you have an encrypted pipe with the bootstrap-node it is exactly that. And from there the bootstrap-node will supply you indeed with IP’s and public keys to connect to others on IP-level. So it has a first layer of encryption, but it’s not safe because these nodes both have each others IP-addres:port public keys etc. So this is where the fun begins going over to XOR. These IP’s wil be each others relay-nodes. So these nodes will both try to join XOR. So they provide their public key to the network, hoping one group will “pick him up”. And that groups will use the public key to respond. So now a node is connected to a group in XOR but the relay-node has no clue what’s going over the pipe. And you are a relay node to someone else as well. So you could actually call it proxy-nodes. And this is a part where a relay-node might trick you into a fake network. But this is also prevented. Don’t ask me the details, because joining in XOR on this level is quite complicated as you’ve seen in the post. I actually need to get my head back in again. Especially in this flow-chart. But thanks for all the questions. Make me think this stuff over and over again. That doesn’t hurt (wel, maybe a bit ;-)), but actually makes us all smarter.

4 Likes
119

Well said my friend. Reinforcement is always helpful in these cases. :smiley:

3 Likes
120

I have not proposed this yet in an RFC, but there is an interesting issue. The network knows when it is about to deliver to a relay node. The address of the client is like (client address, relay node address). So you can imagine the last node connected to the relay node knows it is delivering to the exact relay node. Therefore it is easy for the network to encrypt the last hop direct to the client. i.e. the header saying deliver to client is available to the relay, but the content is encrypted to the client itself. This way relay nodes have no knowledge of what they actually deliver, preventing any sniffing of what is being delivered.

This seems to fix any inbound snooping, the outbound is a bit more complex, but follows the same pattern. This way the relay nodes are really kept in the dark, which means even a broke or fake relay node can cause no snooping issues for us.

5 Likes
121

What if the attacker does what I stated before? Creates a database of chunks they deem illegal then encrypts each them with the target users public key to analyze the appearance of it when encrypted (i.e, fingerprint). As the relay, the attacker waits until the target requests an illegal chunk. Now that the attacker now knows what the chunk in question looks like when encrypted with the targets public key, they can identify that the requested chunk is indeed an illegal chunk. I know that this computationally expensive and impractical, but it is indeed possible right?

To mitigate this I propose that one of the groups (data manager or close group) add some random bits of data before encrypting the chunk with the requesters’ public key. This way the malicious relay will see something other than what he was expecting when relaying an inbound chunk. That would close this attack vector wouldn’t it?