[Feature Request] Cryptostorm Dynamic DNS Services

[parityboy]

This is just me throwing out ideas, based on conversations in this thread.

As part of building a true "dark network", it would be nice if CS offered an on-network DNS resolver. As noted in the linked thread, it would be a fully trusted DNS resolver and additionally (the most important part) it would be a able to support an unregistered on-network TLD, for example ".storm" or ".cs".

This in turn would open up the possibility of on-network, addressable server resources. However, due to the fact that Cryptostorm uses DHCP to provision non-routable IP addresses to clients, stable IP addresses are not available. This though can be mitigated by the deployment of DynDNS.

Typically, DynDNS services are accessed by a user using standard credentials - email/username and password. In contrast, Cryptostorm network connectivity is accessed using an anonymous, randomly generated and hashed token for a username, with a default password.

So similarly to the OpenVPN access offered by Cryptostorm, I propose that such a DynDNS service should use a default password. So then, what should the username be? It can't be a non-persistent anonymous token, because the domain name chosen by a Cryptostorm user must be able to be looked up against something in order to assign it to that user.

So what would be a suitable username? The possibilities are:

• 1) Disposable email address. Easily done, and oddly enough GMail would be ideal for this because:
  • i) it's free
  • ii) it's easy enough to create <random 36-character uuid>@gmail.com, for an email address that won't see any other use.
• 2) Unused BitMessage address. Again BitMessage uses a random string of characters to represent an address.
• 3) Unused Bitcoin wallet address. Similar to BitMessage, a Bitcoin address is a randomly generated string of characters.

Of the three possibilities, I think option 1 is the most easily accessible to the majority of users; bdeff7dd-22ed-42c7-a20e-08ba7ee506ac@gmail.com is anonymous enough to be used as a DynDNS username.

Other Issues
I am not intimately familiar with the Cryptostorm network architecture, but I have taken some educated guesses. Assuming those guesses are inaccurate (I have to assume that they are) and assuming that each VM running on a given cluster node does NOT have it's own DHCP server, and that there is in fact one DHCP server per cluster which provisions connected clients with an IP address, it still means that each cluster has its own 10.55.x.x IP range for clients.

This in turn means that a darknet server connected to a given cluster will not be addressable from another cluster. However, this can be mitigated by

• a) replicating DynDNS data between clusters.
• b) a user's darknet server having a router in front of it which is connected to each cluster's OpenVPN server, and also to each cluster's DynDNS server. pfSense supports this.

Of course there are other non-technical issues with making such infrastructure available - think "what is Tor 'famous' for?" - but nonetheless, I think it would be a fantastic addition to Cryptostorm. I would love to hear the opinions of others on this. Please, chime in.

[~grystch]

Most of this is over my head.
Would this fix dns leak? I like the idea of secure dns, this seem to be that. And the idea of special domain is really cool!
How much extra cost though? I like that low $$$$ price!

~grystch

[parityboy]

Some additional thoughts. Based on my observations, whenever I connect to Cryptostorm I am given an IP address of 10.55.0.x where x always seems to be less than 10. This leads me to believe that either

• a) there's hardly anyone on the cluster at all
• b) there are lots and lots of physical nodes per cluster (possibly a blade server)
• c) each cluster node is heavily virtualised, with lots of small VMs per cluster member and each VM having it's own DHCP server for connected clients.

Since DHCP will always lease the next available IP address, I'm leaning towards a combination of b) and c) which means there aren't that many users per VM. This is further reinforced by some basic ping tests: most addresses in the allocated range do not respond but some do, and there are gaps, leading me to believe that per VM, quite a few are long-term connections (like torrent clients).

On the one hand it means that the cluster is nicely balanced, however on the other hand it means that a user connected to one VM will not be able to route traffic to an on-darknet server connected to another VM, even on the same cluster. By "on-darknet server", I mean a server which never sees traffic from outside of Cryptostorm.

[Fermi]

parityboy, interesting finding.

I have the same experience, I had IP 10.x.0.5 netmask 255.255.0.0. When I disconnected and reconnected I got 10.x.0.3.
1, 2 are responding to ping that's it.
If I try 10.x.1.1; 10.x.2.1 and so on, I get no response.
Does this mean we are only 3 connections on this exit node?
If so, this is not good for our anonymity leaving us to be more or less sitting ducks.

Imagine, only a and b are connected to the exit node. Traffic of a en b from/towards exit node is encrypted, nothing to worry about.
The destinations can of course 'see' the IP address of the exit node, again nothing to worry about.
If one is, by any means (even without compromising the exit node), able to know that the exit node has only two inbound connections, the outbound traffic is originating from a or b, which is not a desirable situation.
One can hardly state that a and b, or even c and d, ... are "lost amidst the crowd". If there are ex. 100+ tokens connected things will of course get more difficult/stochastic ... .

Somewhere in the forum, there's this quote by CS:
Our security model is not based on a shell game of large pools of public IP
addresses. Rather, we route a relatively high volume of network sessions through a
smaller pool of public-facing IP addresses. The benefit of this is the "lost amidst
the crowd" phenomenon and makes traffic analysis all but impossible for even a
well-resourced attacker to successfully deploy. It is worth nothing that traffic
analysis attacks are now, thanks to Snowden, known to be actively utilised by the
NSA and other spy agencies against Tor - it is widely assumed such attacks are or
will be applied to other serious network security services, as well.

I hope CS can convince us that there are a lot more connections, helping to obfuscate traffic ... .

/Fermi

[vpnDarknet]

I've been asked this before, and I'm quite interested, not sure if CS will divulge:
How many active CS users are there?

[parityboy]

@~grytsch

Partially. Once you're connected to a Cryptostorm cluster, the on-network DNS would handle all DNS queries, whether for clearnet hosts or darknet hosts. However, if you've configured your VPN client to use cluster hostnames, rather than cluster IP addresses, somebody's DNS somewhere will know that you are trying to resolve the name of a Cryptostorm exit cluster, probably so that you can connect to it.

As for the extra cost, the real cost is time in setting up and maintaining the DNS server itself. I'd say that to do it properly would require one DNS server (or pair) per exit cluster. Since they would really be virtual machines running on existing hardware, deploying multiple copies wouldn't be very difficult.

@vpnDarknet

Yes that is a good question. I'm sure I read somewhere that it's numbered in the thousands - it would have to be since the team has already stated that this project pays for itself but not much more, and bandwidth and hosting costs aren't exactly cheap.


@Fermi

I think you can rest easy. It's important to bear in mind that users do not connect to "an exit node", as in a single piece of hardware. When you make a connect to CS, you actually connect to a load balancer, which has a number of physical machines sitting behind it - the balancer simply hands off a connection to one of those machines. Furthermore (and based on what I've read), the cluster node which actually handles a given VPN session is a virtual machine which is running the needed software (OpenVPN, MongoDB, DHCP), not a physical node (which only runs a minimal operating system). Additionally, (I assume) there are multiple virtual machines per cluster node. Of course, a "cluster" could also be a single physical machine,with a cluster of multiple virtual machines running on it, fronted by a load balancer. However, this isn't very fault tolerant.


So assuming a CS cluster has 10 machines, and assuming each machine has 10 CPU cores, and assuming the virualisation policy is one virtual machine per processing core plus one left out for the host OS, that's 9 VMs per machine multiplied by 10 machines - 90 virtual machines per cluster. I'm probably inflating the numbers since I don't know the horsepower needed for a high-traffic OpenVPN session, especially with the encryption algorithms being deployed.

Also, don't forget that the 10.55.0.x address range is only for the tunnel between the client and the OpenVPN server running on a given VM. Once your traffic leaves the OpenVPN server, it has to be routed from the virtual machine (which is part of a different IP address range) out to the load balancer, and then back again for the replies. The load balancer won't see the 10.55.0.x address from the tunnel, and the clearnet doesn't see the private address range from the VM - the addresses are NAT'ed at each stage.

So, in order for an attacker to find you, they would have to have control over the entry point (port 443) of the load balancer (to get your IP address) and be able to decrypt all of the traffic going between you and the load balancer (to know what you are doing)- watching the exit side is pointless with that much traffic flowing through it. So while there might not be that many people connected to a given virtual machine on a given physical cluster node on a given cluster, it doesn't mean you can be easily singled out.

[parityboy]

I've just realised that I'd posted something similar earlier in this thread. If mods could lock it (or redirect it here, then any discussion can be posted here instead. Many thanks.

[marzametal]

...assuming they connect via a balancer, rather than an IP from the nodes list.

[parityboy]

@marzametal

The IPs on the nodes list are also balancers, I believe. The DNS names of the individual locations are prefixed with "cluster" as in cluster-iceland.cstorm.pw.

[~grystch]

@~grytsch

Partially. Once you're connected to a Cryptostorm cluster, the on-network DNS would handle all DNS queries, whether for clearnet hosts or darknet hosts. However, if you've configured your VPN client to use cluster hostnames, rather than cluster IP addresses, somebody's DNS somewhere will know that you are trying to resolve the name of a Cryptostorm exit cluster, probably so that you can connect to it.

As for the extra cost, the real cost is time in setting up and maintaining the DNS server itself. I'd say that to do it properly would require one DNS server (or pair) per exit cluster. Since they would really be virtual machines running on existing hardware, deploying multiple copies wouldn't be very difficult.

I like the idea as far as I understand it. But this seems a problem since I thought Crypto storm recommend using hostname not actual ip for connection to the darknet?

~grystch

[parityboy]

@~grystch

Technically it could be an issue if you did not want anyone (i.e. your ISP) knowing you were connecting to a VPN, or Cryptostorm's VPN. The CS team recommend hostnames because IP addresses can and do change. Howvever, it's up to you the user to evaluate your own threat landscape: it wouldn't take that much digging to find out that a given IP address belongs to Cryptostorm, but it's not obvious at-a-glance and connecting to port 443 is innocuous too.

However, if that connection stays up more than 24 hours and has a load of traffic flowing through it, it's either a video security feed or it's a VPN with BitTorrent running through it.


@marzametal

After a brief chat with one of the techs, I learned that in fact there is only one balancer (the global one). The individual IPs belong to single, multi-NIC boxes.

[~grystch]

@~grystch

Technically it could be an issue if you did not want anyone (i.e. your ISP) knowing you were connecting to a VPN, or Cryptostorm's VPN. The CS team recommend hostnames because IP addresses can and do change. Howvever, it's up to you the user to evaluate your own threat landscape: it wouldn't take that much digging to find out that a given IP address belongs to Cryptostorm, but it's not obvious at-a-glance and connecting to port 443 is innocuous too.

However, if that connection stays up more than 24 hours and has a load of traffic flowing through it, it's either a video security feed or it's a VPN with BitTorrent running through it.

Thanks this is intresting. so this also means if you use ip addres the dns leak problem is fixed?? You could find ip of website etc. by look up the name and not have to use dns at all?

http://centralops.net/co/

~grystch

[parityboy]

@~grystch

Effectively yes; once you're connected to the CS network (via the specified IP address of an exit node, to avoid a DNS lookup), all traffic is then routed over the VPN link. If you then specify (for example) the IP address of Google, rather than "www.google.com", no DNS is involved because there is no domain name to resolve into an IP address; you already have the IP address.

[cryptostorm_admin]

We split off this thread, spawning a separate thread with a slightly broader remit than this, which really is focused on in-house DNS resolution. Since that's a viable topic still under active discussion here, the split feels appropriate.

Thank you,

~ cryptostorm_admin