mwarning / KadNode

P2P DNS with content key, crypto key and PKI support. DynDNS alternative.
MIT License
423 stars 74 forks source link

Help verification before DNS/NSS interface #9

Closed mwarning closed 11 years ago

mwarning commented 11 years ago

DSS/NSS can only transmit one IP address. But KadNode may receive multiple IP addresses and will select just the first. Therefore there is a way needed to filter those addresses. This could be done by means of a script etc. that is called in between.

vkefallinos commented 11 years ago

I think the way to solve is by using the key value store.I am not very good at kademlia but as I understand it gives the ability to store two values in the kademlia cloud.such as "domainname:192.168.34.72".the domainname value is searchable. so if the ip is encrypted with private public key cryptography and the one who searches for the domain name knows of the public key he will know the ip adress.are my assumptions right?

mwarning commented 11 years ago

The IP address is taken from the UDP packet address field. You cannot express that a domainname belongs to another IP address except your own (the sender address). This also means that you don't have to implemented some crypto system to prevent spoofing. :-)

Anyway, the problem is that when KadNode receives, let's say, two IP addresses for a hash value (either because your hash value is not random enough or somebody wants to do something bad to you), then KadNode need to call some user program that can check which IP address is legit. When we just pass the first address to the browser and it is the wrong one - the browser will just work with the wrong IP (which might fail or whatever). But KadNode doesn't get any feedback from normal programs like ssh or the browser to sort out wrong IP addresses. One, but crappy way would be to call a user defined program that can do verification and filter IP addresses between the DHT and the DNS interface of KadNode. Well, I don't like that idea. Ideally, the browser would tell KadNode that the IP is invalid (because the certificate doesn't match) and KadNode would blacklist that address from its peer table and search results.

mwarning commented 11 years ago

Another idea would be to blacklist IP addresses that are asked for twice - but that approach is very fragile/broken.

karme commented 11 years ago

Moritz Warning notifications@github.com writes:

The IP address is taken from the UDP packet address field. You cannot express that a domainname belongs to another IP address except your own (the sender address).

maybe i misread but: http://en.wikipedia.org/wiki/IP_address_spoofing

mwarning commented 11 years ago

I wasn't accurate. :-) The source address is taken from the IP header and simply spoofing of the sender address of an UDP packet is trivial since it is stateless; unlike TCP. But Kademlia uses a token that makes it hard to spoof the sender address. In short; I don't think that is a viable road unless we change the DHT protocol.

mwarning commented 11 years ago

Another way, at least for http traffic in the browser would be to write a browser plugin that tells KadNode when an certificate is invalid. I might give this a spin...

mwarning commented 11 years ago

I decided to try to create a protocol plugin for Pidgin that can also use KadNode and that will also address the problem mentioned above. https://github.com/mwarning/plain-prpl

vkefallinos commented 11 years ago

A way to find if an ip is the requested p2p address would be to use a deterministic way to announce instead of one hash multiple hashes derived from the announced value. for example lets say i want to announce mydomain.p2p.Now it would hash mydomain and announce it to the kademlia.Instead of hashing mydomain it could multiple values derived from mydomain.So announce(hash(my)) announce(hash(do)) announce(hash(ma)) announce(hash(in)). and on lookup the reverse is going to happen so it finds the ip that is common in all lookups.This will make it I guess a little slower but more robust.. This is not exactly verification but its better than now..

vkefallinos commented 11 years ago

instead of announcing individual parts of the domainname you could also increase the hash length so it creates lets say 120 character length hash and its then splitted up in 6 hashes that are announced or looked up.

mwarning commented 11 years ago

The idea of splitting the domain name is neat. But I would like to leave all these ideas to programs that are build on top of KadNode and rather remove KadNode for everything that does not need to be there. Anyway, I wrote a somewhat stupid AddrChecker. Maybe that helps in some cases. EDIT: Try AuthAddrs - now with Cryptography. :-)

mwarning commented 11 years ago

That said, it would still be a nice feature for KadNode to have an optional auth module. That way you can make sure the computer behind the IP address has a specific private key.

vkefallinos commented 11 years ago

another good idea is using something like the nightweb protocol https://nightweb.net/protocol.html the idea is use a torrent file that has a public key and the hash of it is the magnet link. so one who wants to announce a domain a password is created tha transforms the domain to the hash of the public key torrent.

mwarning commented 11 years ago

Well, we could do something like this:

This approach is easy and elegant. The only problem I see is that a domain name label is only allowed to be 63 characters long at most. That key size would be next to useless.

Well, I need to check if the browser will pass much longer domain labels to the NSS subsystem. That would be nice.

EDIT1: Verified - I was able to pass <256-characters>.p2p from the browser to KadNode using the NSS interface. libnacl uses 32 Byte public keys (=> 64 characters in hex). So that would work so far. :-)

EDIT2: Work is in progress. :-)

mwarning commented 11 years ago

I have pushed the authentication feature: 5d0f0dc951. Let's hope it is useful. There is a howto in the project wiki.

mwarning commented 11 years ago

Lets close this issue for now. An authentication mechanism (albeit not very secure) has been implemented. Some documentation can be found in the wiki.