US-central exitnode cluster | anchor node = mishigami.cryptostorm.net | updates & "crazy shit"

[cryptostorm_team]

note: folks seeking the most current client configuration files need not wade through this entire discussion thread! The current versions are always posted in a separate, dedicated thread, and will be continuously updated there. Continue reading this thread if you're curious about the details of the config files, want to see earlier versions of them, or have comments/feedback to provide - thanks!

As we've mentioned elsewhere, we have recently completed an upgrade network-wide of our resource management process, known as the Hostname Assignment Framework, or HAF. One benefit of the HAF is dramatically enhanced flexibility in making fast, flexible shifts in server/node resources when circumstances require it.

In recent weeks, that flexibility has been crucial in our response to issues relating to one of our U.S.-based exitnode clusters. Briefly, we've moved to a three-zone U.S. coverage model: useast, uswest, and uscentral. Having downed our useast anchor node due to DMCA-related issues (that cluster will be reborn during Q1 2015, with new datacentre providers & redundant capacity early on), we shifted focus to creation of a strong uscentral cluster, with the deployment of a well-provisioned dedicated machine in Chicago, IL: mishigami.

However, circumstances required us to quickly shift member traffic from that node. Those circumstances (referred to as "crazy shit" more than once, both in twitter & during internal team discussions, if we may be blunt) is being written up separately and will be linked-to from this post when ready for publication.

craaazy_small.png (34.62 KiB) Viewed 33532 times

On an interim basis, we load-shifted uscentral sessions to uswest as we provisioned a new 'mishigami' in the central U.S.

That process is now complete, and mishigami.cryptostorm.net is reborn. Folks curious about such things will note that uscentral HAF lookups now resolve to this anchor node; we expect to have redundant/expansion nodes in place within two weeks, as this cluster continues to grow.

Meanwhile, the prior mishigami has been reborn as mishi.cryptostorm.net - a donated Tor relay (pingdom uptime stats). It carries no member traffic and any cryptostorm-related data has long since been rm'd from the box. Now it stands as a sort of testament to... well, that's best discussed in the "crazy shit" post.

We're quite pleased with the performance of our new uscentral cluster after this series of transitions and adjustments, and we look forward to adding to this cluster as member awareness of its capacity and reliability continues to grow.

• (HAF entries: windows-uscentral.cryptostorm.net/org/nu | linux-uscentral.cryptostorm.net/org/nu)

Finally, we've been asked few times about the naming of our new node. Here's a bit of backstory:

Thank you,

~ cryptostorm_team

[cryptostorm_ops]

We have completed the transition to the newly-architected central US exitnode cluster, anchored by the new node mishigami.cryptostorm.net in Chicago.

All prior HAF mappings pointing to 'chili' are now remapped at the TLD resolver to the relevant mishigami instances. Additionally, mishigami is now in the resource pools for all relevant balancers of whatever OS flavour, having replaced chili's IP-space in that regard.

Further, mishigami is fully HAF 1.4 compliant. Thus, for those who want to get a jump on the use of long-term-stable HAF connection settings, the newly-added resolvers for central US are:

• windows-UScentral.cryptostorm.net
  windows-uscentral.cryptostorm.ch
  windows-uscentral.cryptostorm.nu
  windows-uscentral.cstorm.pw
  
  linux-uscentral.cryptostorm.net
  linux-uscentral.cryptostorm.ch
  linux-uscentral.cryptostorm.nu
  linux-uscentral.cstorm.pw

The HAF 1.4 pooled resolvers (which currently only include Lisbon and central US-based instances, but which will grow to include all nodes and instances as the 1.4 HAF upgrade continues across the network), are and will remain as:

• Sticky (TTL-based, DNS randomised) balancer:
  windows-balancer.cryptostorm.net
  windows-balancer.cryptostorm.ch
  windows-balancer.cryptostorm.nu
  windows-balancer.cstorm.pw
  
  - - - -
  
  Sticky (TTL-based, DNS randomised) balancer:
  linux-balancer.cryptostorm.net
  linux-balancer.cryptostorm.ch
  linux-balancer.cryptostorm.nu
  linux-balancer.cstorm.pw

Finally, here's a pre-release 1.4 version of the linux config file with the central US connection parameters already included:



And here's the text of the document, for those who prefer not to download a separate file:

Code: Select all

# this is the cryptostorm.is client settings file, versioning...
# cstorm_linux-uscentral_3.conf
# last update date: 28 Dec 2014

# it is intended to provide connection solely to the central USA exitnode cluster
# DNS resolver redundancy provided by TLD-striped, randomised lookup queries
# Chelsea Manning is indeed a badassed chick: #FreeChelsea!
# also... FuckTheNSA - for reals. W00d!


client
dev tun
resolv-retry 16
nobind
float

txqueuelen 686
# expanded packet queue plane, to improve throughput on high-capacity sessions

sndbuf size 1655368
rcvbuf size 1655368
# increase pre-ring packet buffering cache, to improve high-throughput session performance


remote-random
# randomizes selection of connection profile from list below, for redundancy against...
# DNS blacklisting-based session blocking attacks


<connection>
remote linux-uscentral.cryptostorm.net 443 udp
</connection>

<connection>
remote linux-uscentral.cryptostorm.ch 443 udp
</connection>

<connection>
remote linux-uscentral.cryptostorm.nu 443 udp
</connection>

<connection>
remote linux-uscentral.cstorm.pw 443 udp
</connection>


comp-lzo no
# specifies refusal of link-layer compression defaults
# we prefer compression be handled elsewhere in the OSI layers
# see forum for ongoing discussion - https://cryptostorm.ch/viewtopic.php?f=38&t=5981

down-pre
# runs client-side "down" script prior to shutdown, to help minimise risk...
# of session termination packet leakage

allow-pull-fqdn
# allows client to pull DNS names from server
# we don't use but may in future leakblock integration

explicit-exit-notify 3
# attempts to notify exit node when client session is terminated
# strengthens MiTM protections for orphan sessions

hand-window 37
# specified duration (in seconds) to wait for the session handshake to complete
# a renegotiation taking longer than this has a problem, & should be aborted

mssfix 1400
# congruent with server-side --fragment directive

auth-user-pass
# passes up, via bootstrapped TLS, SHA512 hashed token value to authenticate to darknet

# auth-retry interact
# 'interact' is an experimental parameter not yet in our production build.

ca ca.crt
# specification & location of server-verification PKI materials
# for details, see http://pki.cryptostorm.ch

<ca>
-----BEGIN CERTIFICATE-----
MIIFHjCCBAagAwIBAgIJAKekpGXxXvhbMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTE0MDQyNTE3
MTAxNVoXDTE3MTIyMjE3MTAxNVowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR
QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM
aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx
FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt
aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDJaOSYIX/sm+4/OkCgyAPYB/VPjDo9YBc+zznKGxd1F8fAkeqcuPpGNCxMBLOu
mLsBdxLdR2sppK8cu9kYx6g+fBUQtShoOj84Q6+n6F4DqbjsHlLwUy0ulkeQWk1v
vKKkpBViGVFsZ5ODdZ6caJ2UY2C41OACTQdblCqaebsLQvp/VGKTWdh9UsGQ3LaS
Tcxt0PskqpGiWEUeOGG3mKE0KWyvxt6Ox9is9QbDXJOYdklQaPX9yUuII03Gj3xm
+vi6q2vzD5VymOeTMyky7Geatbd2U459Lwzu/g+8V6EQl8qvWrXESX/ZXZvNG8QA
cOXU4ktNBOoZtws6TzknpQF3AgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUOFjh918z
L4vR8x1q3vkp6npwUSUwge8GA1UdIwSB5zCB5IAUOFjh918zL4vR8x1q3vkp6npw
USWhgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI
TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5
cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy
eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv
cm0uaXOCCQCnpKRl8V74WzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQAK6B7AOEqbaYjXoyhXeWK1NjpcCLCuRcwhMSvf+gVfrcMsJ5ySTHg5iR1/LFay
IEGFsOFEpoNkY4H5UqLnBByzFp55nYwqJUmLqa/nfIc0vfiXL5rFZLao0npLrTr/
inF/hecIghLGVDeVcC24uIdgfMr3Z/EXSpUxvFLGE7ELlsnmpYBxm0rf7s9S9wtH
o6PjBpb9iurF7KxDjoXsIgHmYAEnI4+rrArQqn7ny4vgvXE1xfAkFPWR8Ty1ZlxZ
gEyypTkIWhphdHLSdifoOqo83snmCObHgyHG2zo4njXGExQhxS1ywPvZJRt7fhjn
X03mQP3ssBs2YRNR5hR5cMdC
-----END CERTIFICATE-----
</ca>

ns-cert-type server
# requires TLS-level confirmation of categorical state of server-side certificate for MiTM hardening.

auth SHA512
# data channel HMAC generation
# heavy processor load from this parameter, but the benefit is big gains in packet-level...
# integrity checks, & protection against packet injections / MiTM attack vectors

cipher AES-256-CBC
# data channel stream cipher methodology
# we are actively testing CBC alternatives & will deploy once well-tested...
# cipher libraries support our choice - AES-GCM is looking good currently

replay-window 128 30
# settings which determine when to throw out UDP datagrams that are out of order...
# either temporally or via sequence number

tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
# implements 'perfect forward secrecy' via TLS 1.x & its ephemeral Diffie-Hellman...
# see our forum for extensive discussion of ECDHE v. DHE & tradeoffs wrt ECC curve choice
# http://ecc.cryptostorm.ch

tls-client
key-method 2
# specification of entropy source to be used in initial generation of TLS keys as part of session bootstrap

log devnull.txt
verb 0
mute 1
# sets logging verbosity client-side, by default, to zero
# no logs kept locally of connections - this can be changed...
# if you'd like to see more details of connection initiation & negotiation

Thank you,

cs_ops

EDIT: removed out-of-date config file
- cryptostorm_support

[cryptostorm_admin]

{archival version of the original post in this thread, now edited to bring current ~admin}

We are currently in process of making some changes and upgrades to the network-side server resources that support our Eastern United States exitnode cluster. Our cluster is anchored by a machine in Virginia, but that DC has been having some issues and we're striping in additional capacity to handle demand for that geographic region.

Under cryptostorm's Hostname Assignment Framework, exitnode clusters are (or more properly, will be - we are in the midst of a full upgrade to HAF compliance, and many pre-HAF associations can still be found in existing configuration files and so forth) are generally identified based on the city in which they are located. This provides a useful balance between geographic specificity, and needless profusions of micro-precise cluster locations that simply make things complex for members.

However in the case of the USA, we're moving towards more of a regional model. We will have West, Central, and Eastern US clusters - thus folks can choose a cluster and not need to lock down to excess detail. Thus far, only the USA has looked to us like it is best served by this approach, although in the future that may change.

Thus, we've taken the opportunity provided by the issues relating to our Virginia-based node (chili) to step forward to this regional model. The first of our central USA nodes - mishigami.cryptostorm.net - will be the first node to embody this evolved approach to cluster-based resource management. Next will come machines to establish a proper Eastern USA cluster, and an expansion of our existing West coast USA presence to ensure redundant network capacity.

To smooth the transition, within the next 24 hours HAF entries associated with chili (and the underlying instances they represent) will see their respective HAF IP-mappings roll forward to the new Central node, mishigami. In terms of functional efficacy - pingtimes, essentially - the geographic shift from Virginia to Chicago is quite small. Still, we wanted to ensure that folks who watch such matters closely understand our thinking in how this is being rolled into production.

Inevitably, there's a bit of turbulence as we move our legacy, pre-HAF structures into full compliance with the HAF model. We are really confident that the benefits provided by consistent HAF mappings vastly outweigh the short-term bumps along the way. And, of course, we're always open to suggestions and critique as we move forward - this is, above all else, a collaborative project.

Already we've been asked as few times about the naming of our new node. Here's a bit of backstory:

michigami.png

HeartSummer.JPG

Thank you,

~ cryptostorm_team

fixed missing quote tag ~parityboy

[Guest]

log devnull.txt

umm- won't that just create a text file named devnull.txt and log to it? would the 'verb 0' stop the loging- man says the command will 'supercede'?
did you mean, log /dev/null? seams it wouldn't be nessasary with the verb 0 setting?

man openvpn:

--log file
Output logging messages to file, including output to std‐
out/stderr which is generated by called scripts. If file
already exists it will be truncated. This option takes effect
immediately when it is parsed in the command line and will
supercede syslog output if --daemon or --inetd is also speci‐
fied. This option is persistent over the entire course of an
OpenVPN instantiation and will not be reset by SIGHUP, SIGUSR1,
or --ping-restart.

Note that on Windows, when OpenVPN is started as a service, log‐
ging occurs by default without the need to specify this option.

[Pattern_Juggled]

log devnull.txt

umm- won't that just create a text file named devnull.txt and log to it? would the 'verb 0' stop the loging- man says the command will 'supercede'?
did you mean, log /dev/null? seams it wouldn't be nessasary with the verb 0 setting?.

Yah, it's kind of an inside joke: devnull.txt... perhaps less funny in the light of day than during long development sessions.

And, yes, verbosity 0 supersedes... we could name the file to which the logs aren't written anything we want. The devnull.txt name has just become something of a tradition with us, fwiw.

Cheers,

~ pj