Basically Q's are:
1) If I am running Cryptostorm client and then on top run the TOR client at the same time, will running Cryptostorm give me an extra layer of security whilst browsing via TOR?
2) If I am running Cryptostorm client and then on top run Freenet at the same time will running Cryptostorm give me an extra layer of security whilst using Freenet?
------------------------------
There's two separate topological models implicit in the question you ask, and each is subtly different in their benefits and drawbacks. And, while this is easier to describe with the benefit of diagrams or a whiteboard, we'll do our best to lay out the basics using only words
The first, and least interesting, approach is to "tunnel cryptostorm through a Tor connection." This is uninteresting because, basically, it won't work: one of the core drawbacks of Tor itself is that the Tor network (due to its routing architecture) cannot handle UDP traffic. As the vast majority of cryptostorm network sessions are UDP-based (we do offer a TCP-over-TCP option for the small number of customers that need it, and are willing to trade off the "TCP panic" performance hit in doing so), it's simply not possible to push a full cryptostorm network session over Tor. So much for that one!
The second, encapsulating/tunnelling Tor through a cryptostorm network session, will function effectively. To do this, one would create a Tor-based network connection (either at the application level, i.e. Tor Browser Bundle-based http/s sessions; or at the network stack level, i.e. Whonix), and then have that session push across a full-scale cryptostorm network session (itself instantiated via the usual widget or command-line, virtual NIC-based architecture). The benefit to this is that the cryptostorm network (the exitnodes through which one's cryptostorm session transits) cannot "see" the traffic which is itself encapsulated within the Tor session itself... so, if one doesn't trust cryptostorm fully (we encourage, wherever possible, a "zero-trust-based" approach to network security, so this is something we actually encourage!), one can be confident that those data are effectively invisible to cryptostorm's server-side admins, or anyone else with /root access to cryptostorm exitnodes. This kind of "layered security" is, in general terms, a good way for those with extra security needs to bolster the core value of their cryptostorm membership: layering ensures that, if one layer breaks down for whatever reason, there's additional 'fallback layers' to (one hopes) ensure a full breach of security requirements is not suffered. Bruce Schneier, amoungst others, encourages this kind of thinking and as with so much Bruce has to say, we wholeheartedly agree.
The downside, in this case, is the inevitable performance lags introduced via the Tor network itself. It's not so much that the layering will cause any performance degradation - tunnelling tunnels through cryptographic tunnels, somewhat surprisingly, is fairly effective in brute-force terms - but rather that the Tor network itself is most assuredly not designed to support high-performance network behaviour. This isn't a criticism of Tor - far from it! - but rather echoes the Tor Project's own admonitions regarding the trade-off of onion routing versus performance (total throughput and/or RTT pingtimes).
tl;dr is that, for a particular browser session or other network activity that is ultra-sensitive, a "Tor over cryptostorm" layered topology may well make sense... but, for most members, attempting to use this setup 24/7 will prove unwieldy and frustrating. Then again, Tor asks folks NOT to use Tor 24/7, so we're just reiterating their own common-sense request that the volunteer-based Tor network not be saturated by individual users.
All the same logical considerations will apply when using Freenet... except that, given Freenet's somewhat novel topological foundations, our tech team doesn't have as much firsthand experience in deploying Freenet-over-cryptostorm configurations. To be honest, we'd encourage you to put this question to our membership itself - via a post in the cryptostorm.ch member forum - to see if others have firsthand experience and advice in such a setup. In terms of our internal tech team, we've done a bit of exploratory work with freenet (and CJDNS, more broadly)... but not enough to be considered useful knowledge resources, at this point in time.
Finally, there's been some interesting chatter in our tech team on the subject of tunneling cryptostorm over cryptostorm itself! These "dual-layer tunnels" hold the promise of full obfuscation of physical/local IP from cryptostorm itself, if set up and implemented properly. We're exploring this as a potential future feature-set for our network access widget, as it's been something of a 'holy grail' to ensure structural obfuscation of member IP... even from our internal admin team. However, apart from internal, staff-based testing at barely-alpha level, we don't have anything to offer in terms of a ready-for-deployment approach to this dual-layer topology. In the future, we hope, that will be something that does come down the pipeline and become available to our larger member community.
If there's any additional data we can provide, please let me know!
Cheers,
~ pj
