zrm / snow Goto Github PK

License: Other

C++ 94.04% C 5.96%

snow's Introduction

snow

snow is a layer 3 virtual network that abstracts the underlying network and allows public keys to be used in place of IP addresses. It can be used even with existing IPv4 applications over IPv4 or IPv6 networks and transparently provides end-to-end encryption and NAT traversal.

trustiosity.com/snow

Build

Dependencies:

C++11 compiler (e.g. g++-4.7 or newer), make
OpenSSL 1.0.1 (libssl)
optional: libminiupnpc (1.5) and libnatpmp

# apt-get install g++ make libssl-dev (optional): # apt-get install libminiupnpc-dev libnatpmp-dev

$ cd src  
$ make -j5

If you don't want libminiupnpc/libnatpmp (or you got some error because e.g. you have a different version of libminupnpc) then you can do this:

$  make -j5 NO_UPNP=1 NO_NATPMP=1

Install

# make install

For additional installation and configuration information see trustiosity.com/snow/how-to-install.html

Use

When you run snow your machine gets a key name like this: baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key.

$ grep "Your key is" /var/log/syslog  
snow: Your key is baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key

When snow is running applications can resolve key names to an IP address. Packets sent to and from that IP address are transparently delivered to and from the machine with that key over a datagram TLS tunnel, e.g.:

$ ping baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key  
PING baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key (172.16.0.2) 56(84) bytes of data.  
64 bytes from baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key (172.16.0.2): icmp_req=1 ttl=64 time=0.611 ms  
64 bytes from baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key (172.16.0.2): icmp_req=2 ttl=64 time=0.588 ms  
^C

Although snow keys are technically names, they are better used in contexts where you might currently use IP addresses.

sdns

sdns is a small DNS resolver daemon. It was created for use with snow but can also be used as a standalone portable recursive caching DNS resolver.

sdns also allows DNS CNAME aliases to be used for key names:

# echo CNAME alice baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key >> /etc/sdns/local.names

$ ping alice  
PING baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key (172.16.0.2) 56(84) bytes of data.  
64 bytes from baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key (172.16.0.2): icmp_req=1 ttl=64 time=0.614 ms  
64 bytes from baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key (172.16.0.2): icmp_req=2 ttl=64 time=0.603 ms  
^C

sdns operates recursively by default, if you want you can set an upstream DNS server like this:

# echo 8.8.4.4 8.8.8.8 > /etc/sdns/forwarders/@

snow's People

Contributors

Stargazers

Watchers

snow's Issues

RFE: access control

I'd like the ability to whitelist people who can connect to me. I'd imagine two main modes-

Whitelisting individual certificates
Whitelisting certificate authorities

Does not compile on debian testing

g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security
-std=c++11 -pthread -std=c++11 -pthread -D_FORTIFY_SOURCE=2 -c -o natpmp.o
natpmp.cpp natpmp.cpp: In function 'void upnp_map_port(uint32_t_,
in_port_t&)': natpmp.cpp:149:94: error: too few arguments to function
'UPNPDev_ upnpDiscover(int, const char_, const char_, int, int, int_)'
UPNPDev devlist = upnpDiscover(2000/_response timeout (milliseconds)/,
nullptr, nullptr, 0);

Application-layer library

There are some great ideas in this project, but like previous attempts to build a system level virtual network, snow has a platform problem: Nobody wants to spend a lot of effort building apps for a platform nobody has installed, and nobody wants to install a system level platform that has no or very few good apps, especially if it's likely to consume background resources running systems like DHTs.

ZeroTier and earlier versions of Telehash suffered from this problem, and neither have been significantly adopted.

One way to improve this is to build an application-layer version, where each application has a public key endpoint and runs it's own node in the DHT. Designing like this eliminates the need to mess with system-level routing or DNS resolution, and provides increased privacy by giving each application it's own address.

If our users have to install some weird system thing that might mess up their DNS if it's buggy, that's a huge barrier.

Request for Permissive Relicensing

Hi zrm,

Would you consider licensing this under a more permissive license than AGPL? Even LGPL would be great. Or MIT, BSD, Apache, what-not.

Inability to derive networks or systems with Snow without releasing source to those networks or systems stands as a pretty imposing barrier to adoption. Changing to a more permissive license may provide some grease to help #1.

Other platforms

To make more people use snow, it would be very welcome to release ports to more platforms (e.g. Android, Windows, etc)

contact problem

it's not possible to send mail to the address published at the webpage

Does NAT traversal for snow include removing the need for p2p workarounds on ipv4?

Can snow be used as a replacement for stun/ice? If so, there's a single abstraction onto both ipv4 and ipv6 for many p2p approaches. This would be a huge win in IoT (eg controlling cameras in a home from a phone outside a home). stun/ice is particularly slow across multiple nat hops.

I am on the outlook for an alternative to tor's ability not to reveal the IP address of an endpoint

I wonder, is there any way to use this to avoid revealing the IP address of a particular server? Tor can do that by running hidden services. Server machines are only known by their onion address, without revealing their IP address. Can snow be repurposed somehow for that same purpose? Or would it be unrealistic?