THESE FILES ARE NO LONGER UPDATED HERE! FOR THE LATEST CONFIGS GOTO our github repositoryMembers connecting via our Windows network access widget do not need to manually download or implement these configuration files, as they are pre-packaged with the widget installer.
This thread exists to serve as a one-stop location for the most current version of the client configuration files for cryptostorm. As new versions complete alpha (internal) and beta (community) testing successfully, they'll be swapped into this post - so that there's always the most current approved configs (and only
the most current versions) here in this thread.
Note that all config files in this post have, as of today (12 January 2014) been upgraded to Hostname Assignment Framework
compliance. This delivers vastly improved session security, resilience, and flexibility as our network continues to grow and expand.
A much deeper discussion of client configuration files, as well as archival copies of earlier versions, can be found in a separate, parallel thread
. To ensure that discussion stays in one place, this post is locked & does not accept replies. Please, if you've got feedback or questions or comments on the config files, post them in the parallel thread
These configuration files vary only
in the choice of exitnode clusters embedded in them, and in their tuning for use with particular operating systems. Otherwise, they are identical to each other. Selected cipher suites, session parameters, and authentication methods are the same. Windows-based members connect to dedicated "instances" of our servers, and mostly everyone else can use the configuration files labelled "Linux." (we used to call those "raw" files but it was a terrible name and so we've moved to just using "Linux," even though it'll support BSD/OSX, and many other operating systems)
You will notice that there's two different ways to do broad-spectrum, "randomised" connections to our global network: dynamic, and settled. We can dig deeper into the differences in these models elsewhere; for here, it's best to think of the "settled" versions being less likely to "jump around" between geographically dispersed nodes during routine network interruptions. Conversely, "dynamic" balancers will be more aggressive in effectively randomising the node to which each session connects - including routine reconnects. Some folks like the extra variability and attack-surface hardening of the dynamic model; others want a bit more stability of node selection and thus the "settled" balancer does well for them.
Otherwise, network connections are made based on exitnode clusters as defined by a city (or, in a small number of cases, a geographic section of a larger country); this, again, relates to the HAF approach to network resilience, and is able to help ensure the network is always available, even with the routine ups and downs of individual nodes.new Singapore anchor exitnode, just provisioned
For our no-cost, capped-speed cryptofree service
Coming soon, or in short-term re-provisioning status: