Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

client config for cryptostorm: general discussion & bughunt

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!
User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

client config for cryptostorm: general discussion & bughunt

Postby cryptostorm_team » Fri Oct 18, 2013 12:14 am

note: folks seeking the most current client configuration files need not wade through this entire discussion thread! The current versions are always posted in Github, 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! :thumbup:


This thread serves both as a minimalist "version control" mechanism for our configuration settings controlling network access, and as a tool to enable easy access to these config and parameter selections as part of our commitment to public disclosure, peer review, and continuous improvement.

Here, you will always be able to find the current versions of our configuration files and other network-connection settings, unedited and as deployed in our pre-compiled network access widget applications. In addition, you can review earlier versions of these settings to see how we've improved and adjusted them over time, as well as proposed future settings that we're currently testing and/or considering.

Finally, this thread will contain most of the basic discussions regarding our configuration selections, why we've chosen them, alternatives we've rejected, and things we'd like to do in future network versions. This is, centrally, an open thread specifically designed to encourage public discussion of these issues - it is through this process that we improve our parameters and thus our network security, over time.

This thread includes not only the client-side configuration options, but also matching server-side parameters. Only by seeing both sides of the connection can a real critique of our security implementation be offered, and so we've chosen to implement full transparency from the beginning in this regard. Security through obfuscation - attempting to hide the details of technical systems, rather than disclose them for peer review - has not proved to be a viable approach to robust, reliable security. We therefore are not obfuscating anything regarding our security model, and will be working to improve disclosure transparency as time goes by.

The versioning mechanism in this thread is rudimentary, but effective. Each subsequent release of a configuration bundle receives a new (numerical) identity, for both client- and server-side settings. Different sub-versions are given alpha suffixes: a, b, c, etc. In the future, this may move to a more formal SCM-style procedure - we'll simply see how it evolves.
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm

User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

cryptostorm_client_production_0-9a.conf | production

Postby cryptostorm_team » Fri Oct 18, 2013 12:45 am

--Graze edit 2013-10-19 08:40p PST: Added ca inline--

This is the client-side (as in, you need THIS ONE if you're hooking up your own client!) configuration currently being distributed to network members.

We have several test-only config bundles that we're using for in-house consideration of new opportunities to tune session dynamics. As they get close to production, we'll post them in this thread so that others may test with them and provide feedback, as well.

We do comment these files fairly heavily, as is obvious during read-over. This helps us both to keep focus on the parameter selections individually, and we hope to help folks less familiar with the syntax of these files to understand what we're doing and our thinking behind it. At the same time, we don't want our embedded commenting to turn into full-length essays or that sort of thing; sometimes, as seen in this file, we'll refer out of the comments back to forum threads here for additional details on selections and considerations.

Finally, you'll see some commented-out parameters that are part of our ongoing testing. We could strip them from production versions of these files, but it seems not productive to do so. These files are a work in progress, and evolve continuously - that's not something that should be hidden, or talked around.


Reminder: all remnants of configuration files in this thread are very old, and you should NOT try to use them to connect; They won't work anyway. Please refer to this thread instead for current, working configurations.

Code: Select all

# this is the cryptostorm.is client settings file, versioning cryptostorm_client_production_0-9a.conf.
# current version of this file can always be found in the most recent post in conf.crytostorm.org .
# please post your comments, questions, suggestions, and observations about config options in that thread.

# also... FuckTheNSA.

client
dev tun
proto udp
remote exitnode_balancer.cryptostorm.org 443
resolv-retry infinite
nobind
# standard setup stuff to identify the network location of the exit node handshake machines.

comp-lzo
# specifies availability of link-layer compression, which is something we're planning to remove in full-production configuration.

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

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

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

fragment 1400
# tunes the UDP session by ensuring packets are split under the upper-bound MTU threshold

# register-dns
# Windows-specific directive to ensure Windows DNS caching doesn't delay registration of new domain resolvers; we're still experimenting with this and haven't placed into production yet.

# script-security 2
# up "client.up"
# down "client.down"
# a *nix-only directive to ensure pushed DNS values are applied & torn down appropriately; still an experimental setting not yet ready for production.

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.

auth-user-pass
# auth-retry interact
# passes up, via bootstrapped TLS, SHA512 hashed token value to authenticate to darknet; 'interact' is an experimental parameter not yet in our production build.


<ca>
-----BEGIN CERTIFICATE-----
MIIFHjCCBAagAwIBAgIJAPXIBgkKVkuyMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTEzMTAxMTEz
NDA0NloXDTE3MDYwOTEzNDA0NlowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR
QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM
aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx
FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt
aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDS4TuqOoT6NrE7oNXj5il97Ml306F9rmEf22+E/5uCsiTNL7inanLsDixihq2l
e0anBK8UvDPExYIWLpXu4ERFFsWS//AoZer8BlVYKnEEgzPh5UV8Jy2TyOlZ26Yz
g1A4MRcDFdPUXLq5Z8hw09k1uqOPU6trv5J+5TwhzMHrMunip8hvx8uXjzQ4DLPK
RKfRzwl+2ydyXgAGdfY1zLlvYvzvVUc4GcLXmAOLT4ZjWKxl4MoqNwf9VBfdLWn5
mWuYp/tT3RxNjKHnuqZlYhCvfWp1hbzSW/OdlO13B1C/PSfFnfFzlANWh31bfvos
pbCIFYG6RXIiP+Arc2sLVgTHAgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUWmCUeZzm
Qa+zcOA+KWfNF1e2Z9cwge8GA1UdIwSB5zCB5IAUWmCUeZzmQa+zcOA+KWfNF1e2
Z9ehgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI
TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5
cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy
eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv
cm0uaXOCCQD1yAYJClZLsjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQDKDYRtxELcCUZwnGvQa8hp5lO/U87yYzOSP3OON4hBS6YWEmRyV3GvZtGibadl
8HbOU0TRS1skcS0g8OfiY+t/qitIpBuLMHgJHubBMWQ5SP9RlSy2ilxt7J+UGbw3
Xi6u7RRG1dOEZkN0RxpbZQeGf7MD6RTI+4JMRvstI0t2wpfAk0eF0FM++iqhR9mu
aH8apEFDUvCQv4NnDrXJqDUJi8Z56SHEJQ5NMt3ugv7vtY3kI7sciuPdW3hDPsJh
/T3cOWUeYeIVknVHwMuUFf6gdxZ8crrWkANpjwOm0gVh1BPRQzXXPKlSVUGgEVFD
XgJyvkX663aTcshEON1+bXp6
-----END CERTIFICATE-----
</ca>

# specification and location of RSA cryptographic keys; for details, see pki.cryptostorm.org .

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

auth SHA512
# data channel HMAC generation; substantial improvement over default digest-generation algorithm.

cipher AES-256-CBC
# data channel stream cipher methodology; not currently known to be formally vulnerable to any theoretical or practical attacks.

# replay-window 128 30
# settings which determine when to throw out UDP datagrams that are out of order, either temporally or via sequence number; this is a test configuration parameter not yet put into production.

tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
# full PFS via selection of ephemeral Diffie Hellman key regeneration & exchange for use in asymmetric control channel renegotiation.
# for details on this discrete logarithm-based alternative to elliptical-curve DHE key generation/synchronisation, see vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html .
# We're still experimenting with ECC-based PFS, but until we develop a deeper confidence in the mechanism for choosing & implementing curves within standard ECC frameworks, we're not deploying
# see this resource for full details: cryptostorm.org/viewtopic.php?f=37&p=5156#p5156 .

tls-client
key-method 2
# specification of entropy source to be used in initial generation of TLS keys as part of session bootstrap.
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby DesuStrike » Tue Nov 19, 2013 9:52 am

I have a personal wish that might benefit everyone:

I am not exactly sure how to pull this off but I would love if there was a way to highlight all changes to the client and server configuration compared to the previous version.

    This would help us with two important things:

  1. It would make it way easier to peer review because we don't have to verify the whole configuration again and again with every change but can concentrate on the modifications you did. We don't need to re-approve stuff we already approved before. (But we are still able to do so from time to time.)
  2. Everyone who cannot just import the configuration file but has to manually type it into whatever form provided by their device (like DD-WRT Routers) would have a way easier time updating. If you look at my DD-WRT guide you'll see that there is lots of stuff that can easily get overlooked if changes are not highlighted, possibly resulting in connection problems or worse.
home is where the artillery hits


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

Re: cryptostorm: config & parameter settings (client & serve

Postby cryptostorm_ops » Wed Nov 20, 2013 1:54 pm

DesuStrike wrote:I am not exactly sure how to pull this off but I would love if there was a way to highlight all changes to the client and server configuration compared to the previous version.


This is something we're keen to support, and is one of the notable weaknesses of our current "post it to a forum thread" style of version control. Just about any more advanced version control system automates this change-highlighting information, so it's easy to see what's changed.

So the question is: what system is best for our next iteration? It's possible to do this manually, of course, via some basic highlighting in a forum thread - different colors, for example. Or we could so something more fancy, like Git-style distributed version control. Basically, we're open to suggestions and advice.

Thank you,

~ cryptostorm_ops

User avatar

cryptostorm_support
ForumHelper
Posts: 296
Joined: Sat Jan 26, 2013 4:31 am
Contact:

BUGFIX for client config - underscore in A record listing

Postby cryptostorm_support » Thu Nov 21, 2013 10:13 pm

BUGFIX for client config!

tl;dr version:

    replace in the client configuration file...
      exitnode_balancer.cryptostorm.org

    with...
      exitnode-balancer.cryptostorm.net


~ ~ ~ ~ ~ ~ ~ ~

A sharp-eyed observer just caught a pretty important error in our current version client configuration file, which could cause connection problems for at least some members. I'm going to quote from his/her message to us, verbatim, and will be happy to give credit for this catch here in this thread if I hear from the person directly that they'd like to have public attribution:

I've noticed that the use of an underscore in the server hostname field of the OpenVPN conf file causes problems when trying to setup a pfSense router as a client to the CryptoStorm network. The particular line I'm referring to is this one

Code: Select all

Line #10:  remote exitnode_balancer.cryptostorm.org 443


IIRC, underscores are not a valid character in DNS hostnames, but hyphens are.

The "ASSUMPTIONS" section of RFC 952 states that;

    'A "name" (Net, Host, Gateway, or Domain name) is a text string up
    to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
    sign (-), and period (.).'

Can the client OpenVPN .conf file please be updated according to prevent any more compatibility issues with other devices?

I'm using the server IP address in my configuration as a workaround in the meantime.


And here was the reply that I forwarded on, which includes the new information to fix this bug:

That's an excellent catch.

We make use of underscores extensively in our internal VM naming conventions; it appears that one managed to jump out of that context and into an A record. As you say, that's outside the RFC and could well cause real problems.

We've added an A record for exitnode-balancer.cryptostorm.org (as well as exitnode-balancer.cryptostorm.net as we're moving to multiple redundant TLD mappings for load balancing mechanism to preemtively harden against TLD-based DNS de-listing attacks by state-level entities, in future config revisions), so feel free to update your own conf to the proper hyphenated version, as it will map correctly currently and in the future.

I'll also go ahead and post this to the forum thread as a suggested revision to the existing conf version - and put it to our ops team to see if they'll go ahead and do a formal version update on the client config to get this fix out as widely as possible.

Thanks for pointing this out - it's quite likely already caused problems for some members, and would cause more if we'd not had your assistance in catching it now!

Best regards,

~ cryptostorm_support
cryptostorm_support shared support team forum account
PLEASE DON'T SEND PRIVATE MESSAGES with support questions!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby DesuStrike » Thu Nov 21, 2013 11:21 pm

cryptostorm_ops wrote:
So the question is: what system is best for our next iteration? It's possible to do this manually, of course, via some basic highlighting in a forum thread - different colors, for example. Or we could so something more fancy, like Git-style distributed version control. Basically, we're open to suggestions and advice.


Ah I didn't realize there were an answer to my inquiry.

Git would be fancier indeed but I guess it would overstrain some non git users to navigate there. I also like that we got almost everything here on the forums and using git would break with that habit...

I think for the time being a "changelog" like in the post above is pretty much sufficient.
The downturn is that in the long run it could become pretty chaotic to look for the newest changes if discussion here intensifies in future.

hmm... This is again a problem with a non obvious solution... I still would give the greentext a try.
home is where the artillery hits


b3lt3r5
Posts: 27
Joined: Sun Dec 23, 2012 2:55 pm

Re: BUGFIX for client config - underscore in A record listin

Postby b3lt3r5 » Sat Nov 23, 2013 8:04 am

cryptostorm_support wrote:BUGFIX for client config!

tl;dr version:

    replace in the client configuration file...
      exitnode_balancer.cryptostorm.org

    with...
      exitnode-balancer.cryptostorm.net


~ ~ ~ ~ ~ ~ ~ ~

A sharp-eyed observer just caught a pretty important error in our current version client configuration file, which could cause connection problems for at least some members. ...

~ cryptostorm_support



I was unable to connect using Viscosity for Mac.
I can confirm this fix solved the problem. :clap:


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

client config, 0.9d

Postby cryptostorm_ops » Sat Dec 07, 2013 8:14 am

Here's an interim update to the client configuration file; it'll be formally announced as 1.0 soon, and posted to the main website, but for folks who would like to have the tweaks sooner here you go.

Nothing major has been changed, just a few minor bugfixes that we'll document formally during the 1.0 release. A few performance enhancements via small adjustments to MTU window settings, and more work to turn off the "comp-lzo" compression settings from both directions.

Also, this version has ca.crt inlined inside the file, so there's no need for an external ca.crt - mandatory for Android folks, and also handy for other OS flavours. We believe this has been tested across platforms, and are planning to include the inlining with the 1.0 build.

Enjoy!

Code: Select all

# this is the cryptostorm.is client settings file, versioning cryptostorm_client_production_0-9d.conf.
# current version of this file can always be found in the most recent post in conf.crytostorm.org .
# please post your comments, questions, suggestions, and observations about config options in that thread.

# also... FuckTheNSA.

client
dev tun
proto udp
remote exitnode-balancer.cryptostorm.net 443
resolv-retry infinite
nobind
float
# standard setup stuff to identify the network location of the exit node handshake machines.

comp-lzo no
# specifies availability of link-layer compression, which is something we're planning to remove in full-production configuration.

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

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

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

fragment 1400
# tunes the UDP session by ensuring packets are split under the upper-bound MTU threshold

# register-dns
# Windows-specific directive to ensure Windows DNS caching doesn't delay registration of new domain resolvers; we're still experimenting with this and haven't placed into production yet.

# script-security 2
# up "client.up"
# down "client.down"
# a *nix-only directive to ensure pushed DNS values are applied & torn down appropriately; still an experimental setting not yet ready for production.

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.

auth-user-pass
# auth-retry interact
# passes up, via bootstrapped TLS, SHA512 hashed token value to authenticate to darknet; 'interact' is an experimental parameter not yet in our production build.

ca ca.crt
# cert clientgeneric.crt
# key clientgeneric.key
# specification and location of RSA cryptographic keys; for details, see pki.cryptostorm.org .

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

auth SHA512
# data channel HMAC generation; substantial improvement over default digest-generation algorithm.

cipher AES-256-CBC
# data channel stream cipher methodology; not currently known to be formally vulnerable to any theoretical or practical attacks.

replay-window 128 30
# settings which determine when to throw out UDP datagrams that are out of order, either temporally or via sequence number; this is a test configuration parameter not yet put into production.

tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
# full PFS via selection of ephemeral Diffie Hellman key regeneration & exchange for use in asymmetric control channel renegotiation.
# for details on this discrete logarithm-based alternative to elliptical-curve DHE key generation/synchronisation, see vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html .
# We're still experimenting with ECC-based PFS, but until we develop a deeper confidence in the mechanism for choosing & implementing curves within standard ECC frameworks, we're not deploying
# see this resource for full details: cryptostorm.org/viewtopic.php?f=37&p=5156#p5156 .

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

<ca>
-----BEGIN CERTIFICATE-----
MIIFHjCCBAagAwIBAgIJAPXIBgkKVkuyMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTEzMTAxMTEz
NDA0NloXDTE3MDYwOTEzNDA0NlowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR
QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM
aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx
FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt
aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDS4TuqOoT6NrE7oNXj5il97Ml306F9rmEf22+E/5uCsiTNL7inanLsDixihq2l
e0anBK8UvDPExYIWLpXu4ERFFsWS//AoZer8BlVYKnEEgzPh5UV8Jy2TyOlZ26Yz
g1A4MRcDFdPUXLq5Z8hw09k1uqOPU6trv5J+5TwhzMHrMunip8hvx8uXjzQ4DLPK
RKfRzwl+2ydyXgAGdfY1zLlvYvzvVUc4GcLXmAOLT4ZjWKxl4MoqNwf9VBfdLWn5
mWuYp/tT3RxNjKHnuqZlYhCvfWp1hbzSW/OdlO13B1C/PSfFnfFzlANWh31bfvos
pbCIFYG6RXIiP+Arc2sLVgTHAgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUWmCUeZzm
Qa+zcOA+KWfNF1e2Z9cwge8GA1UdIwSB5zCB5IAUWmCUeZzmQa+zcOA+KWfNF1e2
Z9ehgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI
TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5
cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy
eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv
cm0uaXOCCQD1yAYJClZLsjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQDKDYRtxELcCUZwnGvQa8hp5lO/U87yYzOSP3OON4hBS6YWEmRyV3GvZtGibadl
8HbOU0TRS1skcS0g8OfiY+t/qitIpBuLMHgJHubBMWQ5SP9RlSy2ilxt7J+UGbw3
Xi6u7RRG1dOEZkN0RxpbZQeGf7MD6RTI+4JMRvstI0t2wpfAk0eF0FM++iqhR9mu
aH8apEFDUvCQv4NnDrXJqDUJi8Z56SHEJQ5NMt3ugv7vtY3kI7sciuPdW3hDPsJh
/T3cOWUeYeIVknVHwMuUFf6gdxZ8crrWkANpjwOm0gVh1BPRQzXXPKlSVUGgEVFD
XgJyvkX663aTcshEON1+bXp6
-----END CERTIFICATE-----
</ca>


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

Version 1.1(a) client config files

Postby cryptostorm_ops » Sat Dec 21, 2013 6:09 pm

We've just completed a major overhaul of our exitnode/cluster nomenclature, hostname mappings, and loadbalancing framework. One of the results is a fork of the client configuration file into four separate files, depending on which exitnode connection logic members prefer. Briefly...

    1. locked
    2. dynamic
    3. Frankfurt-only
    4. Montreal-only


There's also some minor tuning of secondary parameters in these config files, as compared to the latest numbered revs released previously.

NOTE: while all the parameters & A record mappings have been fully tested, we are posting these config files to this thread in hopes of a broader testing of them by members themselves before they are considered "official." There's nothing in them that should be a problem... but as with all tech, the proof is in the deployment. Please, if you give any of these config files a run and experience problems of any kind, let us know right away via post here (preferred) or via other channels.

There's plans for a much more thorough explanation of these new cluster/node architectures and the ways in which they scale over time - for example, when our Icelandic node is ready for production. For now, our hope is that these can help folks who have older versions of configs, or who want to take advantage of node/cluster selection by choosing their preferred config file version from this batch.



EDIT: removed old, unusable configuration files

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby DesuStrike » Sat Dec 21, 2013 11:17 pm

If we shouldn't comment in this thread please tell me. I'll (or you can) create a separate thread for comments and discussion

I'll go ahead with asking about two things that otherwise maybe not find their way into the thorough explanation because they look like blunders to me:

1. resolv-retry 16
Why only 16 instead of the former infinite? Does it only change to another machine inside the cluster if those 16 retries are used up or can it change with every retry? To my knowledge after those 16 retries the client gives up to connect altogether. :think:

2. register-dns
There are two entries with this command, both with different comments. One is located after "down-pre" the other one is located after "fragment 1400". :eh:
home is where the artillery hits

User avatar

severide
Posts: 27
Joined: Sun Nov 10, 2013 1:09 am

Re: cryptostorm: config & parameter settings (client & serve

Postby severide » Sun Dec 22, 2013 3:13 am

The formatting on those 4 configs files is messed up. At least it looks that way to me. There are no breaks/new lines, just one long line. I'm currently going through one config (dynamic) and breaking up the lines.
cryptofree via iOS
CS Node List
CS Wiki maintained by vpnDarknet
PGP
Bitmessage: BM-2cUCkRBnNEhhW3qyNoEpRK6LtQjUs281wT

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby DesuStrike » Sun Dec 22, 2013 4:54 am

severide wrote:The formatting on those 4 configs files is messed up. At least it looks that way to me. There are no breaks/new lines, just one long line. I'm currently going through one config (dynamic) and breaking up the lines.


I can't confirm that. the contents of all four files are neatly arranged when I look at them. It's always a pair of one command and then a short explanation.

Could it be that you are on Windows? With what editor are you viewing the config?
home is where the artillery hits

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby DesuStrike » Sun Dec 22, 2013 5:25 am

For easy reference I used a text comparison tool for both the Version 0.9d and Version 1.1 Frankfurt.

It's always interesting to see the actual differences and I hope we get information to why those changes besides the "stochastic variance in IP allocations within the cluster" were made.

Now with the direct comparison it's pretty much obvious that the double "register-dns" is a blunder.

I'm still interested in:
  1. Why reduce the retries from infinite to 16?
  2. Is "proto udp" negligible because the exit node only accepts UDP anyways?
  3. Is the increase of the "hand-window" time a reaction to the fact that clients sometimes ended up in an infinite loop because the session got dropped prematurely? Is increasing this number relevant to security?
  4. Doesn't "float" open up ways to do a MitM attack? (It's not new but I just saw it.)
Attachments
home is where the artillery hits

User avatar

severide
Posts: 27
Joined: Sun Nov 10, 2013 1:09 am

Re: cryptostorm: config & parameter settings (client & serve

Postby severide » Sun Dec 22, 2013 5:29 am

DesuStrike wrote:Could it be that you are on Windows? With what editor are you viewing the config?


I was just about to post this. I originally opened them up with Notepad (on windows). I went back and opened the files with Sublime Text 3 and Notepad++ and they're all formatted correctly. Weird.
cryptofree via iOS
CS Node List
CS Wiki maintained by vpnDarknet
PGP
Bitmessage: BM-2cUCkRBnNEhhW3qyNoEpRK6LtQjUs281wT

User avatar

spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby spotshot » Sun Dec 22, 2013 10:28 am

if I used conf file as is I got these warnings using openvpn,
link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'


b3lt3r5
Posts: 27
Joined: Sun Dec 23, 2012 2:55 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby b3lt3r5 » Sun Dec 22, 2013 4:07 pm

severide wrote:The formatting on those 4 configs files is messed up. At least it looks that way to me. There are no breaks/new lines, just one long line. I'm currently going through one config (dynamic) and breaking up the lines.


Use WordPad. It can handle unix line break encoding.
Right click and choose "Open with..."

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby DesuStrike » Sun Dec 22, 2013 9:01 pm

spotshot wrote:if I used conf file as is I got these warnings using openvpn,
link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'


First: I am very very sorry Spotshot! I clicked on EDIT instead of QUOTE and kinda... deleted a part of your post in an attempt to just quote this section. I was totally confused why my post won't show until I saw my words in your post. This Forum Theme still gives me a really hard time because freakin' everything looks the same! Please accept my apologies. Please post the missing information again, if you want to!

Still, here is my answer:

This is strange stuff indeed.

Normally the default MTU size should be 1500 and thanks to fragment cut off at 1400. Don't ask me why it is clever to cut one packet into two on a regular basis, but I'm sure the team has good reasons for that.

I really don't get why you have MTU = 1602 and I even more don't understand why he thinks the exit node has 1606. There is absolutely no MTU parameter (other than fragment) on the client side and the server config explicitly states tun-mtu 1500. (That is, if the team didn't change something server side without notifying us. But I don't think they would do that.)

So there is some crazy shit going on on your side.

My suggestion is that you try to add "tun-mtu 1500" to your config. It will fix your MTU size but it won't do nothing remote wise. Still worth a try.
home is where the artillery hits

User avatar

spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby spotshot » Sun Dec 22, 2013 9:21 pm

tun-mtu 1500 - add it where ?


the rest of my post
I was able to connect, but could not get any webpages,
if I just added
remote cluster-frankfurt.cryptostorm.net 443
into the old config from 12/7, I could get online and pages load fine,
however speeds dropped to about 2mb,
this has always been about the normal speed when I connected in eu

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby DesuStrike » Sun Dec 22, 2013 9:36 pm

Just in a new line somewhere into the config that gives you these MTU related errors.
AFAIK the commands don't need to be in a specific order. They just need to be there. I always add customizations two lines in front of the inline certificate.
home is where the artillery hits

User avatar

spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby spotshot » Sun Dec 22, 2013 10:03 pm

no change, same warning on mtu.

its fine, im sticking with older config file from 12/7

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm: config & parameter settings (client & serve

Postby Pattern_Juggled » Mon Dec 23, 2013 2:41 pm

Some of the version control logic on these configs has fallen on my desk for the time being, so I'm going to take a shot at revisions and explanations as some of the rest of the team is semi-afk this holiday week.

DesuStrike wrote:For easy reference I used a text comparison tool for both the Version 0.9d and Version 1.1 Frankfurt.


Those are very handy comparators - thanks for posting them!

It's always interesting to see the actual differences and I hope we get information to why those changes besides the "stochastic variance in IP allocations within the cluster" were made.


The logic & syntax of loadbalancing/round-robin really needs to be a separate post, as it gets a bit technical and is something that's certainly going to be evolving over time. So I'm going to suggest we open a separate thread for "loadbalancing & DNS-block redundancy," so it has room to stretch its legs...

Now with the direct comparison it's pretty much obvious that the double "register-dns" is a blunder.


Yah, good catch. I've pushed that update to the production candidates.

Why reduce the retries from infinite to 16?


Resolve-retry is only for hostname resolution of the "--remote" parameter - not retrying the session itself. Thus, if an attempt to resolve a particular hostname for exitnode identification - let's say for example "cluster-montreal.cstorm.pw" - fails to return an IP (or, more likely, list of IPs) from the upstream DNS provider (all the way up to the canonical DNS resolver, i.e. nameservers), this parameter specifies how long the client should wait before giving up and going on to the next hostname in the <connections> consideration set.

With multiple redundant TLD-based hostnames across a set of divergent registrars, tuning this parameter to 16 (i.e. 16 seconds) makes sense; with only one hostname to use, it wouldn't (as in previous config files). That's because, let's say someone at a local ISP blocks one of our canonical domains from resolving, via brute-force DNS block (remember: until the encrypted session is completed, the client must rely on preexisting DNS resolution settings, in order to resolve the remote hostnames and thus bootstrap the session): anything *.crstorm.pw fails to resolve. This is a ham-fisted form of "VPN blocking" to see nowadays... but it does still happen in some countries, and in some private networks (i.e. schools, big companies, some sorts of "nannyware" filtering tools, etc.). In this case, the cryptostorm client will wait 16 seconds for a DNS reply, and if it doesn't get one, it goes on to the next (randomly) selected <connection> profile in the consid set.

Only by blocking all of the extant TLDs being used for domain/remote hostname redundancy can someone actually block the initiation of cryptostorm sessions via standard DNS censorship.

Is "proto udp" negligible because the exit node only accepts UDP anyways?


Definitionally, it's the client that proposes the protocol for the network session within the OpenVPN framework. It's true that the exitnodes won't handshake with TCP-based sessions, but it'd be poor parameter syntax to just let this happen via defaulting client-side; better (cleaner) to specify UDP client-side so the specifications for control channel initiation can be negotiated as efficiently as possible. Clients initiate session requests, always, in our model so it is the clients that carry the burden of specifying how they want to connect; the server-side resources 'push' down a minimum set of parameters (only those that we might be updating more often than is practical for client configs, which tend to be 'sticky' and not get updated as often in real-world deployments) and the clients specify the rest.

    Too, of course, the exitnodes won't authenticate clients that can't support the required cipher suites - but that's a bit of a different issue.


Is the increase of the "hand-window" time a reaction to the fact that clients sometimes ended up in an infinite loop because the session got dropped prematurely? Is increasing this number relevant to security?


Yes, the earlier hand-window sessions did leave some connections aborting because the handshake hadn't completed fast enough. This was particularly the case in "lossy" network transit situations, where packets were getting dropped & retransmits were required - if this happened during session negotiation, the old settings proved a bit too "tight" to complete successfully.

As to security, we've already dialed this parameter waay back from the defaults. Broadly speaking, there's a declining return to (inverse) scale in pulling it asymptotically closer to zero: the whole idea is to make active MiTMs tougher by ensuring the window's not sloppily long; once you've got down to 30 seconds or so, you've already made the lion's share of impact on hardening against these vectors. By far.

Doesn't "float" open up ways to do a MitM attack? (It's not new but I just saw it.)


No, not that I'm aware.

Float allows the client's IP to change during an authenticated session. This happens routinely during longer cryptostorm sessions - we're seeing members nowadays that are connected continuously for more than a week, for example, and many local routers re-lease DHCP'd addys every 24 hours - and without it the session hard-aborts in mid-stream and needs to be rebuilt from scratch.

It doesn't present a substantive MiTM risk increase, in our particular security model. That's because HMAC.

We place a fairly heavy emphasis on HMAC authentication of every single packet in a session, and if HMAC's fail, the packets are dumped. Thus, being able to throw packets at a session key'd TLS tunnel that don't have the "right" IP address doesn't do any attacker any good: without the correct HMAC, the packets are tossed summarily. A session hijack needs to replicate those HMACs perfectly - and that's nontrivial. Very nontrivial, in my personal opinion... bordering on infeasible.

We are also quite picky about out of order control channel packets, and control channel packets that get timestamped too far out of expectation: they get dumped, and if they happen repeatedly the session hard-aborts. Again, the ability to initiate "spoofing" of source IP on these wouldn't help an attacker successfully hijack a session at all given these constraints - they still have to ensure their injected packets meet session key & temporal parameter specifications to a fairly high standard. Possible, but not simple - and needs to be done on conjunction with successful HMAC spoofing.

The computational overhead of the HMAC parameters we've chosen is very high. We believe it's more than worth it, given the core role HMAC fingerprinting plays in ensuring session integrity and hardening against hijack attempts. Frankly, sloppy HMACing is indefensible given what is now known about NSA (and other) automated MiTM attacks against secured "VPN service" sessions online.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm: config & parameter settings (client & serve

Postby Pattern_Juggled » Mon Dec 23, 2013 2:54 pm

DesuStrike wrote:Just in a new line somewhere into the config that gives you these MTU related errors.


This will depend, also, on whether someone's using the widget to connect or making "raw" connections. The widget bundles its config options & handles some of that setup slightly differently than plain-vanilla OpenVPN instances... and there's also the random variability of Windows itself, and how it decides to do things once it gets its hands on things.

Once these new configs are settled, we'll roll a new version of the widget installer for Windows, embedding them in that package as well. Currently, the widget's config settings are a bit "behind" the raw ones posted in this thread - that's something we're working to synchronise via the deployment of a pushed-update framework for the widget (more on that from the development folks, although likely not until after the holidays, from what I've heard).

For example, some OSes simply ignore the client-side specification of MTU parameters... depending on the mood they're in. There's no way for OpenVPN (or any userland application) to "make" the kernel - or network stack, do anything. They can ask, and the OS can do it - or not.

If you're curious, there's a great deal of in-depth technical data on the entire issue of MTU parameterization on the OpenVPN project's wiki, and related links. It's a deep subject area. We've been fiddling with MTU settings and OpenVPN deployments since 2008 - I remember initial tests from back in those days, and the dearth of published info on recommended settings. Nowadays, there's almost too much information - much of it mutually contradictory. Given the enormous variability in setups that network members have when connecting to cryptostorm, there's no "right answer" for this kind of parameter optimization... nor even, to be honest, a Pareto optimal point on the possibility landscape.

Rather, there's an ongoing process of tuning parameters, watching network performance stats in aggregate, and using one's experience and gut-feel to make test adjustments on given nodes in a form of crude A/B comparative metrics. You can see some of that in the development of the config files posted here, which is one reason we're keeping them all and not just removing old ones - it's interesting to see the development, and how real-world production demands impact the selection of network parameters.

AFAIK the commands don't need to be in a specific order. They just need to be there. I always add customizations two lines in front of the inline certificate.


Mostly, that's true: ordering of parameters within config files is not relevant to parsing.

There's a few issues relating to specifications of <connection> block options that are, in recent OpenVPN versions, sequence-dependent... but that's the exception to the rule that has historically held.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

cleanup edits: client config 1.1(b)

Postby Pattern_Juggled » Mon Dec 23, 2013 3:03 pm

Ok, I've unilaterally made some "clean-up" edits to these 1.1 client config files, and I'm posting the newly-edited versions here for review and further testing. Note that I'm not incrementing them numerically, nor am I (yet) removing the ones posted earlier in this thread by ops - it seems tedious to do so, given these are (imho) procedural edits.

The two things I've changed are:

    1. removed duplicate "--register-dns" setting (although I believe the parser just ignores dupes);
    2. commented out the MTU setting client-side, entirely

As to #2, the ops folks seem to think that we might have less error throws (which isn't the same thing as actual session problems, but still is a laudable goal) with the MTU parameters functionally pushed down from server-side... and if this flows smoothly in production, it also allows them to dynamically adjust these settings from the network side of things without cluttering client config files with a bunch of tiny version increments along the way.

The server-side MTU characteristics are determined by:

Code: Select all

tun-mtu 1500
fragment 1350
mssfix
# tunes the UDP session by fragmenting below the MTU upper bound


These directives, in turn, unpack into sub-directives that are somewhat differently processed depending on OS and client. Internal testing suggests that, on balance, this process results in better throughput for connected clients... but there's a dollop of black magicks in this as, again, there's so much stochastic variability in the network transit characteristics for each connecting client.

So... if you would be so kind, give these rigs a whirl. I'll work to get some text written up on the loadbalancer logic - which veers into a subject close to my heart: axiomatic set theory. If that's also fascinating to you, be glad that you'll have the chance to apply your Cantorian insights to an actual, real-life example of a production system dependent heavily on the respective set-theoretic model chosen for use in framing the system design process itself.

Yay! :thumbup:



EDIT: removed old, unusable configuration files
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby spotshot » Tue Dec 24, 2013 3:32 am

same warning, switched back to older config from 12/7

Mon Dec 23 16:30:51 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Dec 23 16:30:51 2013 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
Mon Dec 23 16:30:51 2013 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby DesuStrike » Tue Dec 24, 2013 5:14 pm

Hey PJ,

thank you very much for taking the time to answer all my questions! I didn't expect any answer until after the holidays and thus it's nice to see you are still arond and take care of things!

I'm on the hop to my family so I don't have time to try out the new config but I'll definitely do! If it runs smooth on my PC I'll downgrade my Android to 4.2 so I can enfroce a fixed set of DNS-servers. With this it will be safe to activate the DNS-Proxy, enabling me to use domain names for the VPN connection rather than a raw IPs. I wonder if Arne Schwabes client is even capable to cope with multiple remote entries.


Happy Holidays to you, your family and the team!
home is where the artillery hits

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby DesuStrike » Wed Dec 25, 2013 11:49 am

Results are in:

Ubuntu (Network Manager Plug In): I can connect to the VPN but that's it. URLs won't resolve to IPs and ping commands to raw IPs won't go through either. It's like being offline but while being connected to the VPN.

Similar results on Android.

So basically: The new config is absolutly unuable for me.
home is where the artillery hits

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm: config & parameter settings (client & serve

Postby Pattern_Juggled » Wed Dec 25, 2013 5:52 pm

Spotshot has nailed it on this one; it appears that the MTU settings need to be precisely synched on client & server-side. This was not previously the case, and is not a documented requirement in any of the underlying literature... but I have also confirmed, with my own testing, that this MTU issue is enough to result in loss of packet throughput.

Fortunately, it's an easy fix. I've gone ahead and pushed revisions to these configs that sync with the current server-side settings... with some reservations, as we'd prefer to push MTUs up to the client side versus down to what's on servers currently. But, doing so would require a full cycle of server.conf rev's and, frankly, during the holiday weeks that's not a good idea in terms of staffing, testing, and post-deployment support.

Thus, for 1.1 we're going to synch to server-side MTU.

Also, we're in the process of creating a separate thread for the current client.conf files to be kept in - no replies, just a "parking" thread that's easy for folks to find. This thread, here, will continue to be the "working" thread for conf-related issues and discussions of various config settings. But it's becoming tough for folks to jump right to the most current client.conf files in the midst of the discussions here, which isn't helpful.

Thanks, spotshot, for the early flag to this odd bug in the current OpenVPN builds! I must admit that, when I read your results, I couldn't see in theoretical terms how it would result in loss of packet transit via the exitnode gateways... and really I still don't understand what exactly is going on with that. I'm sure our ops folks can shed light on it when they're back on post-vacation availability... but in the meantime, it's enough to know that this dependency has appeared in the current framework - & thus must be worked thru.


edited to add: here's a link to the new repository for current-version client config files - the subdomain conf.cryptostorm.org is also in process of being redirected over to that thread, as it's likely to be the place most folks go who just want to grab the most-current config files.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

client config 1.1(c)

Postby Pattern_Juggled » Wed Dec 25, 2013 6:25 pm

As I should have done earlier, I'm going to stick a version-control label on these client config files of 1.1(c) - the two earlier versions, posted up above in this thread, would this be (a) and (b), respectively. It just goes to show that skipping nomenclature can serve to curse a deployment - fair warning to the unwise amoungst us... :o

Note, the only change that has been made between 1.1(b) - as posted above - and these 1.1(c) versions below is a change of the --fragment directive parameter from 1400 to 1350; this brings it in line with server-side settings, as can be seen in the server.conf posting earlier in this thread.

    (slightly puzzling testing note: for several weeks, our internal staff testing has been making use of the -- fragment 1400 parameter client-side with no problems whatsoever - it is, at this point, something of a mystery why that setting was happy in that internal testing but is manifestly sad when deployed in these 1.1 client settings... a more careful review of the error logs will likely shed light on what's going on under the covers at the packet-by-packet level, but at the surface level it's something of a surprising turn of events - such is tech...)

These 1.1(c) versions are also posted at present in the conf.cryptostorm.org "current version" thread, but since that thread is going to purge old versions when new ones are pushed to production, every rev should also be crossposted here in this thread so it's available archivally.

Without further ado, here's the four 1.1(c) configs:



EDIT: removed old, unusable configuration files
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm: config & parameter settings (client & serve

Postby Pattern_Juggled » Wed Dec 25, 2013 6:37 pm

DesuStrike wrote:I'm on the hop to my family so I don't have time to try out the new config but I'll definitely do! If it runs smooth on my PC I'll downgrade my Android to 4.2 so I can enfroce a fixed set of DNS-servers. With this it will be safe to activate the DNS-Proxy, enabling me to use domain names for the VPN connection rather than a raw IPs. I wonder if Arne Schwabes client is even capable to cope with multiple remote entries.


I believe Graze can answer that question, and I'll put a query in to him for consideration after the holidays. He's been working on our internal Android build for months, and is pretty familiar with Arne's codebase on a line-by-line basis... far more so than I am.

Also, somewhere out there I've seen a nice little script for iptables that allows for near-continuous updating of rules based on DNS parameters rather than merely IP entries: this allows, for example, "whitelist" settings that are canonical, rather than numeric, which is handy for things like anti-leak deployments on secure network sessions. I believe I bumped into those scripts during leakblock research... but I have to go back and review my notes to get more specific than that based on memory alone, unfortunately.

I'll be surprised if Arne's Android client can't handle non-IP entries in the --remote directive, since it's such a common method of deploying connection information. That said, I've been surprised enough times that I'm no longer all that surprised at being surprised :eh:

And yes, word is that Graze is returning his attentions to the dedicated cryptostorm fork of Arne's Android client first thing in the New Year. He's had an internal/alpha version of it that works very well for months, but has turned his focus to the token system during that time. The work needed to proof his alpha rev for a beta deployment is not enormous: mostly UI issues, and Play store hoops through which it must be jumped. And some version control tediousness that I'm enforcing, as is par for the course, but which synchronise with a pushed-update framework we're currently testing for the cross-platform widget codebase itself.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby DesuStrike » Wed Dec 25, 2013 11:53 pm

Hey PJ,

at least in the Frankfurt config you commented out the fragment command. Just sayin' ;)


Edit:

New results are in!

Ubuntu works like a charm when you uncomment the fragment command.

Arne Schwabes Client refuses to import with: "unsupported option connection encountered in config file. Aborting..."

Seems like it has problems with the multiple URLs after all.
home is where the artillery hits

User avatar

spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: cryptostorm: current version client config files

Postby spotshot » Fri Dec 27, 2013 7:38 am

same warning with newest config files

Thu Dec 26 20:35:21 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Dec 26 20:35:23 2013 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
Thu Dec 26 20:35:23 2013 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

un-commenting the fragment line correctly - finally

Postby Pattern_Juggled » Sat Dec 28, 2013 5:07 am

spotshot wrote:same warning with newest config files

Thu Dec 26 20:35:21 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Dec 26 20:35:23 2013 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
Thu Dec 26 20:35:23 2013 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'


Thanks for staying on top of this, spotshot & DesuStrike.

It appears that my holidays-addled mind managed to leave the new "--fragment 1350" line commented out (with the pound sign - # - starting the line), which would result in the errors continuing to be thrown.

I've fixed the production versions, re-uploaded to my post in this thread, and pushed the edit out through the conf.cryptostorm.org thread to the production version (should be updated already).

For the record, this is why I'm not such a good resource for version control stuff - not my strong point (I'm a systems topologist, not a version control maestro!) :angel:
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f


wax24
Posts: 10
Joined: Sun Dec 29, 2013 11:56 pm

Re: cryptostorm: config & parameter settings (client & serve

Postby wax24 » Mon Dec 30, 2013 5:20 am

Sorry to report i am still getting the errors with these same configs i just re-downloaded today:

Sun Dec 29 10:53:22 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Dec 29 10:53:25 2013 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
Sun Dec 29 10:53:25 2013 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'

I looked for the "fragment 1350" in each of the configs and it is present not commented out.

I also cannot seem to ping out with these new configs once it finishes connecting. I always ping out immediately after connecting to make sure i am routing out properly and with these new configs my pings just fail.

I am using a Windows 2003 VM on Virtualbox to connect if that matters.

"cryptostorm_client_production_0-9b.ovpn" has been working ok on this same VM so i'll be stuck using that until i figure this out.

Any ideas? Thanks in advance.


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

Re: cryptostorm: config & parameter settings (client & serve

Postby cryptostorm_ops » Mon Dec 30, 2013 2:09 pm

We've been testing configs and config deployments all weekend long, and are now complete with the server-side updates. I'll be posting up the new rev client configs this morning, as we deploy the necessary tweaks to the server-side parameters to support both the new adjustments and, as far as is possible, all backwards-compatible issues with prior client configs.

There is some... undocumented behavior in the way OpenVPN handles some of these parameters in certain OS settings, particularly the "fragment" directives and the "comp-lzo" compression settings; the syntax of errors tends to blur these two issues together, unfortunately, and it takes considerable forensic analysis to determine which is really causing issues in a given setting. Our team has been engaged in extensive, manual testing of all possible settings in config space, this weekend, to ensure we've determined these behaviors firsthand - not merely relying on the documentation.

We hope to push back some of our findings into the OpenVPN's project framework, as they could be useful to others who are deploying the tool in more cryptographically-intensive, security conscious settings. Basically, some of these parameters start to interact oddly when parameters are (broadly speaking) tightened up and packet-level errors are taken seriously.

We'll be posting out our results, as I said, throughout this morning - full details in this thread, as always.

Thank you,

~ cryptostorm_ops


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

cryptostorm_client_locked1_1f.conf

Postby cryptostorm_ops » Mon Dec 30, 2013 4:33 pm

Here's the guts of the 1.1(f) version of the client config family; we're posting it here for review by folks who are helping to refine this generation of the settings.

Note that server-side conf has been substantively updated over the weekend, so if you've tested config settings previously they may work better now that the server updates have been pushed to production across the network.

A decisions has been made by the ops team to standardise on a MTU length target of 1400 for the current generation of cryptostorm's framework. This also maintains backwards-compatability as best possible for current network members. That's a variance from earlier instances of the latest version configs posted here, which were moving towards a setting of 1350. This could not be maintained given compatability and other issues in the network.

Here is the text file of the (f) iteration of the 'locked' config; all other flavours will follow identical parameters, save for differences in <connection> constellations and round-robin logic:


Code: Select all

# this is the cryptostorm.is client settings file, versioning...
# cryptostorm_client_locked1_1f.conf

# it is intended for randomised initial selection of geographic exitnode cluster...
# then retention of specific node IP across session restarts within that cluster
# current version of this file can always be found in http://conf.crytostorm.org

# also... FuckTheNSA.


client
dev tun
resolv-retry 16
nobind
float

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


<connection>
remote exitnode-balancer.cryptostorm.net 443 udp
</connection>

<connection>
remote exitnode-balancer.cryptostorm.org 443 udp
</connection>

<connection>
remote exitnode-loadbalancer.cstorm.pw 443 udp
</connection>

<connection>
remote exitnode-loadbalancer.cryptostorm.nu 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.org/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

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

fragment 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.org

<ca>
-----BEGIN CERTIFICATE-----
MIIFHjCCBAagAwIBAgIJAPXIBgkKVkuyMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTEzMTAxMTEz
NDA0NloXDTE3MDYwOTEzNDA0NlowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR
QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM
aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx
FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt
aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDS4TuqOoT6NrE7oNXj5il97Ml306F9rmEf22+E/5uCsiTNL7inanLsDixihq2l
e0anBK8UvDPExYIWLpXu4ERFFsWS//AoZer8BlVYKnEEgzPh5UV8Jy2TyOlZ26Yz
g1A4MRcDFdPUXLq5Z8hw09k1uqOPU6trv5J+5TwhzMHrMunip8hvx8uXjzQ4DLPK
RKfRzwl+2ydyXgAGdfY1zLlvYvzvVUc4GcLXmAOLT4ZjWKxl4MoqNwf9VBfdLWn5
mWuYp/tT3RxNjKHnuqZlYhCvfWp1hbzSW/OdlO13B1C/PSfFnfFzlANWh31bfvos
pbCIFYG6RXIiP+Arc2sLVgTHAgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUWmCUeZzm
Qa+zcOA+KWfNF1e2Z9cwge8GA1UdIwSB5zCB5IAUWmCUeZzmQa+zcOA+KWfNF1e2
Z9ehgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI
TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5
cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy
eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv
cm0uaXOCCQD1yAYJClZLsjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQDKDYRtxELcCUZwnGvQa8hp5lO/U87yYzOSP3OON4hBS6YWEmRyV3GvZtGibadl
8HbOU0TRS1skcS0g8OfiY+t/qitIpBuLMHgJHubBMWQ5SP9RlSy2ilxt7J+UGbw3
Xi6u7RRG1dOEZkN0RxpbZQeGf7MD6RTI+4JMRvstI0t2wpfAk0eF0FM++iqhR9mu
aH8apEFDUvCQv4NnDrXJqDUJi8Z56SHEJQ5NMt3ugv7vtY3kI7sciuPdW3hDPsJh
/T3cOWUeYeIVknVHwMuUFf6gdxZ8crrWkANpjwOm0gVh1BPRQzXXPKlSVUGgEVFD
XgJyvkX663aTcshEON1+bXp6
-----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.org

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 1
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


wax24
Posts: 10
Joined: Sun Dec 29, 2013 11:56 pm

Re: cryptostorm: client config discussions, bugs, requests,

Postby wax24 » Tue Dec 31, 2013 2:01 am

Thanks for the new configs. I gave them a try and they seem to have the same or maybe even worse problems for me. They generate more messages anyway... :

Mon Dec 30 12:54:32 2013 OpenVPN 2.3.2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013
Mon Dec 30 12:54:38 2013 UDPv4 link local: [undef]
Mon Dec 30 12:54:38 2013 UDPv4 link remote: [AF_INET]46.165.222.207:443
Mon Dec 30 12:54:38 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Dec 30 12:54:44 2013 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
Mon Dec 30 12:54:44 2013 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'
Mon Dec 30 12:54:44 2013 [server] Peer Connection Initiated with [AF_INET]46.165.222.207:443
Mon Dec 30 12:54:48 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Dec 30 12:54:48 2013 open_tun, tt->ipv6=0
Mon Dec 30 12:54:48 2013 TAP-WIN32 device [VPN] opened: \\.\Global\{5F406EDC-0BC6-44EC-9401-448E0A2BD54C}.tap
Mon Dec 30 12:54:48 2013 Set TAP-Windows TUN subnet mode network/local/netmask = 10.77.0.0/10.77.0.2/255.255.0.0 [SUCCEEDED]
Mon Dec 30 12:54:48 2013 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.77.0.2/255.255.0.0 on interface {5F406EDC-0BC6-44EC-9401-448E0A2BD54C} [DHCP-serv: 10.77.255.254, lease-time: 31536000]
Mon Dec 30 12:54:48 2013 Successful ARP Flush on interface [2] {5F406EDC-0BC6-44EC-9401-448E0A2BD54C}

Once it finishes connecting there is the same problem of not being able to ping out and within a minute or so it actually disconnects.

Since you mentioned differing results with different operating systems i am going to assume this is happening because i'm connecting with a Windows 2003 VM? Strangely, "cryptostorm_client_production_0-9b.ovpn" works for me. I'll keep using it for now.


wax24
Posts: 10
Joined: Sun Dec 29, 2013 11:56 pm

Re: cryptostorm: client config discussions, bugs, requests,

Postby wax24 » Tue Dec 31, 2013 2:15 am

I went ahead and just edited my .9b configs (since it works) for the other exit nodes and Frankfurt seemed to connect and allow routing out. I checked my geoIP location and it showed Germany so seems good so i'll stick with these for now. No rush on my part for new configs. Thanks.

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm: client config discussions, bugs, requests,

Postby Pattern_Juggled » Fri Jan 03, 2014 4:11 pm

As I'm sure folks have noticed, there's been a flurry of tweaks and tests being done on the server-side configuration settings across all the exitnode clusters this week. Looking back, it might not have been ideal to do this during a holiday week, as some of our ops staff was only transiently available - but the idea was to get these final edits pushed to production before the January rush of members and network traffic.

Anyway, it sounded like a good idea at the time...

Unfortunately, at one point yours truly was left as the sole officer on deck & as I lack some of the subtlety of the real ops crew, my approach to binding new config params to running openvpn daemons is... well, crude. As in "killall -9" ...yes, I know, I know.

There's lots of stuff that's come out of this testing - some genuine breakthroughs, some serious bugs identified on the openvpn codebase, and some much-needed reconsideration of scaling frameworks now that we've got so many different folks connecting via so many different OS and local package flavours. Looking back to 6 months ago, I don't think any of us really had an intuitive sense of the exuberant diversity of connection flavours we'd be supporting by this point in time. Indeed, I doubt there's many folks worldwide supporting as wide a variety of platform ecosystems with substantive, non-default cipher frameworks enabled and required in the "VPN industry" currently.

Short version of what's going on:

    First, client-side config files are forking for specific OS/platform needs. This became absolutely impossible to ignore, when a corner-state status was reached in seeking to support all known/deployed cryptostorm client-side config settings out in the wild presently: in set theoretic terms, it's possible to cover most of the terrain with a given server-side parameterization version..,. but not all of it, and even to do most of it, some subclasses get suboptimal performance while others get excellent performance. There is no "sweet" spot in which all sets overlap and get the performance we expect to deliver. Such should exist, in theory (and according to the terms specified in the canonical documentation for the codebase. But in terms of post-compile actual behaviour... nope. Source code review confirms that these are deep structural issues with the OpenVPN codebase itself - Yonan and the rest of the team on the project are aware of the issues, and we've every confidence they'll resolve them in 3.x in a typically competent, professional, solid way. In the meantime, it's a bit of a snarled mess when it comes to heavily-tuned parameters and wide OS support. I personally verified this, after the Ops crew reported this as the final result of testing, by (per note above) doing some brute-force commits to production instances over the holidays. And, indeed, the behaviors reported by the ops crew replicate and can be reproduced consistently. It is not an isolated issue; it is the underlying codebase. So, the solution is both practical and in fact optimal for maximal performance and maximal compatibility (both backwards- and lateral): for the configs. Done.

    Second, we've rolled out several cloned test ecosystems for the kind of production-equivalent config deployment tuning that we've been trying to do all through December without having negative impact on actual network members. Some of these resources will be made available to beta testers specialising in specific OS/platform deployments, to help ensure access to robust data for production builds.

    Third, we're moving to a formal version control methodology for the landscape of config snapshots across exitnode clusters. This is, at our current scale, mandatory - it is functionally infeasible to do this effectively via manual process. Again, I can attest to that firsthand - we're past the point where anything else can produce full network services reliably, consistently, durably, and professionally. There's still a bit of a religious struggle going on in within our team as to what this methodology will be... but if I have any say, we'll be doing Subversion. I know: old-school. Sometimes that's best.

    Fourth: we've taken the chance during all this to rip open the guts of kernel-level TCP/packet management optimization (a subject near and dear to my grizzled old academic's heart). This best spawns a separate thread as it's not directly config-param related, but it does overlap somewhat as we're intertwining some openvpn config optimizations (txqueuelen 256 | sndbuf 655368 | rcvbuf 655368) with kernel-level (sysctl) tweaks. For members pushing higher-bandwidth sessions, these optimizations can make an enormous improvement on sustained throughput... up to and above 100megabit+ consistent packet transit.

    Fifth: internally we've had some success in optimised ECDHE curve specifications for production deployments. This is, again, only indirectly related to the whole config issue... but not totally unrelated. It's likely that we'll produce some beta daemons on selected exitnodes (Iceland, to begin) for folks who are comfortable self-compiling local OpenSSL libraries with source modifications suggested by our dev folks. Additionally, we're doing some very early work (well, this is my area so the royal "we" is less appropriate) in partnership with Baneki Privacy Labs on providing access to lattice-based cipher algorithms for those who desire to "quantum-proof" their network comms. If you're not sure what that means, then you're probably not going to want to mess with this... but if you are, you'll likely find it somewhat intriguing. I do, anyway. :-)

This might be a bit caddywompus as the pieces of the new framework get striped into production this weekend and details are posted into the forum - but we're looking to have it all in place, and documented here, before next week. We're staffed to document things well, and deploy things well... but rarely both simultaneously. Hence: deploy, then document. So it goes...

Cheers,

    ~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

cryptostorm_client_iceland1_2.conf

Postby cryptostorm_ops » Mon Jan 06, 2014 6:32 pm

We have incremented our client-side configuration to version 1.2, as we implement forked configuration options for OS/ecosystem flavours.

This is the first 1.2-class configuration file presented for public use and validation, and is specific to our new Icelandic exitnode cluster. It is intended for "raw" OpenVPN sessions; config settings for Windows widget sessions, iOS connections, and other subclasses are currently being prepared for release.



Code: Select all

# this is the cryptostorm.is client settings file, versioning...
# cryptostorm_client_iceland1_2.conf

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


client
dev tun
resolv-retry 16
nobind
float

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


<connection>
remote cluster-iceland.cryptostorm.net 443 udp
</connection>

<connection>
remote cluster-iceland.cryptostorm.org 443 udp
</connection>

<connection>
remote cluster-iceland.cryptostorm.nu 443 udp
</connection>

<connection>
remote cluster-iceland.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.org/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

fragment 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.org

<ca>
-----BEGIN CERTIFICATE-----
MIIFHjCCBAagAwIBAgIJAPXIBgkKVkuyMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTEzMTAxMTEz
NDA0NloXDTE3MDYwOTEzNDA0NlowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR
QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM
aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx
FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt
aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDS4TuqOoT6NrE7oNXj5il97Ml306F9rmEf22+E/5uCsiTNL7inanLsDixihq2l
e0anBK8UvDPExYIWLpXu4ERFFsWS//AoZer8BlVYKnEEgzPh5UV8Jy2TyOlZ26Yz
g1A4MRcDFdPUXLq5Z8hw09k1uqOPU6trv5J+5TwhzMHrMunip8hvx8uXjzQ4DLPK
RKfRzwl+2ydyXgAGdfY1zLlvYvzvVUc4GcLXmAOLT4ZjWKxl4MoqNwf9VBfdLWn5
mWuYp/tT3RxNjKHnuqZlYhCvfWp1hbzSW/OdlO13B1C/PSfFnfFzlANWh31bfvos
pbCIFYG6RXIiP+Arc2sLVgTHAgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUWmCUeZzm
Qa+zcOA+KWfNF1e2Z9cwge8GA1UdIwSB5zCB5IAUWmCUeZzmQa+zcOA+KWfNF1e2
Z9ehgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI
TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5
cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy
eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv
cm0uaXOCCQD1yAYJClZLsjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQDKDYRtxELcCUZwnGvQa8hp5lO/U87yYzOSP3OON4hBS6YWEmRyV3GvZtGibadl
8HbOU0TRS1skcS0g8OfiY+t/qitIpBuLMHgJHubBMWQ5SP9RlSy2ilxt7J+UGbw3
Xi6u7RRG1dOEZkN0RxpbZQeGf7MD6RTI+4JMRvstI0t2wpfAk0eF0FM++iqhR9mu
aH8apEFDUvCQv4NnDrXJqDUJi8Z56SHEJQ5NMt3ugv7vtY3kI7sciuPdW3hDPsJh
/T3cOWUeYeIVknVHwMuUFf6gdxZ8crrWkANpjwOm0gVh1BPRQzXXPKlSVUGgEVFD
XgJyvkX663aTcshEON1+bXp6
-----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.org

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

User avatar

spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: cryptostorm: client config discussions, bugs, requests,

Postby spotshot » Mon Jan 06, 2014 7:54 pm

new cryptostorm_client_iceland1_2 works fine, connects with no issues

however,
the other 4, dynamic1_1 frankfurt1_1 locked1_1 montreal1_1
get these warning when connected, without access to net

Mon Jan 06 08:50:41 2014 OpenVPN 2.3.2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013
Mon Jan 06 08:50:49 2014 UDPv4 link local: [undef]
Mon Jan 06 08:50:49 2014 UDPv4 link remote: [AF_INET]46.165.222.207:443
Mon Jan 06 08:50:49 2014 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Jan 06 08:50:50 2014 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
Mon Jan 06 08:50:50 2014 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'
Mon Jan 06 08:50:50 2014 [server] Peer Connection Initiated with [AF_INET]46.165.222.207:443
Mon Jan 06 08:50:53 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Jan 06 08:50:53 2014 open_tun, tt->ipv6=0
Mon Jan 06 08:50:53 2014 TAP-WIN32 device [Local Area Connection 12] opened: \\.\Global\{02E042B9-249F-4CE9-AAAA-6660EF72536F}.tap
Mon Jan 06 08:50:53 2014 Set TAP-Windows TUN subnet mode network/local/netmask = 10.77.0.0/10.77.0.5/255.255.0.0 [SUCCEEDED]
Mon Jan 06 08:50:53 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.77.0.5/255.255.0.0 on interface {02E042B9-249F-4CE9-AAAA-6660EF72536F} [DHCP-serv: 10.77.255.254, lease-time: 31536000]
Mon Jan 06 08:50:53 2014 Successful ARP Flush on interface [65540] {02E042B9-249F-4CE9-AAAA-6660EF72536F}
Mon Jan 06 08:50:58 2014 Initialization Sequence Complete


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

Re: cryptostorm: client config discussions, bugs, requests,

Postby cryptostorm_ops » Mon Jan 06, 2014 9:22 pm

spotshot wrote:the other 4, dynamic1_1 frankfurt1_1 locked1_1 montreal1_1
get these warning when connected, without access to net


That's correct - the other four conf files are being forked to Windows & "raw" dedicated daemons on each exitnode, which should be done shortly once testing of the IP mappings is completed in-house. In the meantime, we make the Icelandic exitnode available only to "raw"/direct connections to bridge the gap until the forking is complete.

~ cryptostorm_ops


wax24
Posts: 10
Joined: Sun Dec 29, 2013 11:56 pm

Re: cryptostorm: client config discussions, bugs, requests,

Postby wax24 » Mon Jan 06, 2014 10:48 pm

I wanted to let you know this new "cryptostorm_client_iceland1_2.conf" seems to work for me now on my Win 2003 VM too. Good progress! Thanks!

Edit!*!* A few hours later i unfortunately have to report few disconnects from the Iceland server. This is from USA midwest. I'll keep testing it..

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: client config discussions, bugs, requests,

Postby DesuStrike » Tue Jan 07, 2014 12:02 pm

Yesterday I tried the Iceland node and it constantly reconnected every 2 minutes or so.
home is where the artillery hits


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

Iceland 1.2

Postby cryptostorm_ops » Wed Jan 08, 2014 4:38 pm

DesuStrike wrote:Yesterday I tried the Iceland node and it constantly reconnected every 2 minutes or so.


What client/OS are you using for those connections? The current mapping has been essentially *nix-specific, on an interim basis. We are in the midst of deploying OS-specific bindings in Iceland right now, in order to support widget connections, Android connections, iOS connections, and generic/*nix connections most effectively.

The 1.2 Iceland config has been tested specifically for command-line Linux with excellent throughput and stability - but not as yet for other platforms. That is currently, again, in process.

Thank you,

~ cryptostorm_ops

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: client config discussions, bugs, requests,

Postby DesuStrike » Wed Jan 08, 2014 5:13 pm

Ah well, ok.

Then the problem was that I used my Android phone and connected via IP rather than the URL.
home is where the artillery hits

User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

forked server configuration 1.2 now in production

Postby cryptostorm_team » Fri Jan 10, 2014 6:09 pm

After a somewhat astonishingly complex process, we've now deployed across all exitnodes the full 1.2 "forked" network session framework. This is a short post to let folks know what's going on - we'll be writing up a more detailed synopsis of the theory behind all this, and the substantial future benefits this change offers to the network in terms of flexibility, performance, and even a bit of increased security.

First, if you're connecting with the Windows widget - any previously-released versions - then there should be no changes, no need for you to do anything. You may have seen your session drop this morning as patches and upgrades were applied. That's it. If you are seeing problems, let our support staff know! Ensuring full backwards-compatibility with all existing widget builds has been a top priority for us.

Second, if you've changed your "remote" setting in the widget's configuration file, then do read this little summary as it will likely be relevant to you!

Ok, now the details in high-level form...

We have created a new layer of logic in the "remote" connections to exitnodes and clusters. The widget (and other Windows-based network sessions) previously connected to the same daemons (processes or instances are also accurate, pick your preference) on specific physical machines as do all our other "raw" connections from members with Linux, Android, or other OSes. That was becoming a serious bottleneck, as there's ample opportunity to tune specific OS sessions. Thus, the forking decision we've made.

From here forward, Windows-specific sessions will be connecting always via "remote" sessions of the form:

Code: Select all

windows-iceland.cryptostorm.net  |  windows-frankfurt.cryptostorm.net


...and so on. These subdomains, in turn, direct to specific daemons within those exitnode clusters that are tuned for Windows/widget network sessions. So, generally speaking, Windows sessions will in the future always be pointed at Windows-specific remote daemons (which are in fact separate IPs on specific machines in a given cluster). [note: current widget builds use a generic 'exitnode_balancer.cryptostorm.org' remote mapping, which has now been redirected to Windows-specific daemons via A record-based DNS remappings]

For "raw"/Linux connections there are now a suite of specific remote options, such as...

Code: Select all

 raw-frankfurt.cryptostorm.net | raw.montreal.cryotostorm.net


...and so on. We will be posting a full list of those mappings, so folks can make use of them selectively. Additionally, the official 1.2 client configurations are being polished for distribution by our support folks right now.

Finally, there's "stubs" in the framework for dedicated daemons to support custom-config sessions for iOS, Android, and other client-side platforms that each have special ways they can be tuned... but only if the server supports them. Well, all of our nodes and clusters now support this tuning ability - and we'll be expanding that as we go, across the network.

~ ~ ~

This has been, in a word, epic. We began work on this in early December, when reports of buggy behavior in the "MTU/fragment" directive started rolling in. It became clear that, to really support full performance tuning without and slip in security and resilience, we needed to completely rethink our approach to a "unified" configuration for different OS flavours. With the growing volume of exitnodes and clusters in our network, and with our desire to support backwards compatibility for everyone, this became a logistic puzzle in many dimensions.

We pushed to finish this over the holidays, when things are generally slower, but it kept surprising us with complex challenges. Many recompiles, retests, rearchitectings, and re-thinkings later, we've got things in hand. This last push to deploy the tested framework has now taken place, and we're in clean-up mode.

Speaking of... it's likely there will be a batch of unforeseen IP/fqdn mapping bugs left over from this - so please let us know if you're seeing something unexpected. And, if you're getting "hung" network sessions because of the dreaded "inconsistent use of MTU settings" or "bad header compression" warnings in logfiles, that's a sign you're getting routed to the wrong daemon on a given node. Let us know, and we'll get it sorted.

Everyone on the team has been pitching in with the testing and deployment of this upgrade. And, while it's not very glamorous - redesigning an encapsulation framework for session routing isn't exactly what most folks consider "sexy" - it has opened up a big space for future improvements, extensions, and feature additions. We knew this big upgrade was going to be needed, so we've bitten the bullet and gotten it done now - before the network grows even bigger. Anyway, what this means is that our replies to emails and bitmessages has been much slower than usual - we grabbed our support staffers and used them brutally as testers throughout this so everyone's been pulled into the vortex in the meantime.

Why so complex, you might ask? Simple: since we don't store ANY central "account" information for network members, anywhere, the challenge of enabling exitnode/cluster selection becomes considerable. Unprecedented, as nobody has ever built a secure network with our decentralised framework. This has not been a trivial challenge, and as clusters have been added, the need has become more and more obvious. It's been an adventure.

Now, we're back to the daily work of production: administration, performance tuning, minor bug identification. More, we're able to get back to work on further security enhancements, refinement of the widget framework, widget builds for additional OS flavours, and so on. Finally.

Thanks for the debugging and oversight help we've received from network members, in the last few weeks. This has been an adventure, and it's one we've all gone through together.

We'll post a link here when our ops folks write up more details on the implementation & how it can be used by network members to choose their clusters, nodes, and OS preferences.

Best regards,

    ~ cryptostorm_team
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm

User avatar

marzametal
Posts: 498
Joined: Mon Aug 05, 2013 11:39 am

Re: cryptostorm: client config discussions, bugs, requests,

Postby marzametal » Sat Jan 11, 2014 8:38 am

Congrats on all the work behind the scenes!
I would like to mention that I had no internet response when using "windows-frankfurt.cryptostorm.net". I switched to the Iceland one and all was swell...


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

windows-frankfurt-cryptostorm.net

Postby cryptostorm_ops » Sun Jan 12, 2014 2:49 pm

marzametal wrote:Congrats on all the work behind the scenes!
I would like to mention that I had no internet response when using "windows-frankfurt.cryptostorm.net". I switched to the Iceland one and all was swell...


Thanks for the bug report - we did find an erroneous A record mapping that had been propagated. That has been resolved, and this mapping - windows-frankfurt.cryptostorm.net - should be resolving to the correct IP/instance within the Frankfurt exitnode cluster.

If you have a chance to test that out, please let us know what your results are so that we can be sure we've flushed the incorrect mapping.

Thank you,

~ cryptostorm_ops


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

cryptostorm client config 1.2 - Frankfurt

Postby cryptostorm_ops » Sun Jan 12, 2014 2:53 pm

We have tested and confirmed functionality for the following "raw"/Linux client configuration file, which is intended for dedicated connections to the Frankfurt exitnode cluster:

If you see any unexpected or anomalous behaviors when using this config, please post a note here so that we can investigate at once. Thank you.

Code: Select all

# this is the cryptostorm.is client settings file, versioning...
# cryptostorm_client_raw-frankfurt1_2.conf

# it is intended to provide connection solely to the Frankfurt exitnode cluster
# DNS resolver redundancy provided via connection TLD round-robin logic
# Chelsea Manning is indeed a badassed chick: #FreeChelsea!
# also... FuckTheNSA - for reals


client
dev tun
resolv-retry 16
nobind
float

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


# frankfurt cluster
<connection>
remote raw-frankfurt.cryptostorm.net 443 udp
</connection>

<connection>
remote raw-frankfurt.cryptostorm.org 443 udp
</connection>

<connection>
remote raw-frankfurt.cryptostorm.nu 443 udp
</connection>

<connection>
remote raw-frankfurt.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.org/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

fragment 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.org

<ca>
-----BEGIN CERTIFICATE-----
MIIFHjCCBAagAwIBAgIJAPXIBgkKVkuyMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTEzMTAxMTEz
NDA0NloXDTE3MDYwOTEzNDA0NlowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR
QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM
aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx
FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt
aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDS4TuqOoT6NrE7oNXj5il97Ml306F9rmEf22+E/5uCsiTNL7inanLsDixihq2l
e0anBK8UvDPExYIWLpXu4ERFFsWS//AoZer8BlVYKnEEgzPh5UV8Jy2TyOlZ26Yz
g1A4MRcDFdPUXLq5Z8hw09k1uqOPU6trv5J+5TwhzMHrMunip8hvx8uXjzQ4DLPK
RKfRzwl+2ydyXgAGdfY1zLlvYvzvVUc4GcLXmAOLT4ZjWKxl4MoqNwf9VBfdLWn5
mWuYp/tT3RxNjKHnuqZlYhCvfWp1hbzSW/OdlO13B1C/PSfFnfFzlANWh31bfvos
pbCIFYG6RXIiP+Arc2sLVgTHAgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUWmCUeZzm
Qa+zcOA+KWfNF1e2Z9cwge8GA1UdIwSB5zCB5IAUWmCUeZzmQa+zcOA+KWfNF1e2
Z9ehgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI
TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5
cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy
eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv
cm0uaXOCCQD1yAYJClZLsjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQDKDYRtxELcCUZwnGvQa8hp5lO/U87yYzOSP3OON4hBS6YWEmRyV3GvZtGibadl
8HbOU0TRS1skcS0g8OfiY+t/qitIpBuLMHgJHubBMWQ5SP9RlSy2ilxt7J+UGbw3
Xi6u7RRG1dOEZkN0RxpbZQeGf7MD6RTI+4JMRvstI0t2wpfAk0eF0FM++iqhR9mu
aH8apEFDUvCQv4NnDrXJqDUJi8Z56SHEJQ5NMt3ugv7vtY3kI7sciuPdW3hDPsJh
/T3cOWUeYeIVknVHwMuUFf6gdxZ8crrWkANpjwOm0gVh1BPRQzXXPKlSVUGgEVFD
XgJyvkX663aTcshEON1+bXp6
-----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.org

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


Lignus
Posts: 33
Joined: Sat Nov 02, 2013 1:26 am

Re: cryptostorm: client config discussions, bugs, requests,

Postby Lignus » Sun Jan 12, 2014 4:50 pm

Ran some DNS checks, the .nu domain had either not propagated or has not been updated. In addition, it looks like one of the .net ones was overloked:

Begin Report
raw-montreal.cryptostorm.net
Name: raw-montreal.cryptostorm.net
Addresses: 198.50.119.172
70.38.46.224

raw-montreal.cryptostorm.org
Name: raw-montreal.cryptostorm.org
Addresses: 198.50.119.172
70.38.46.224

raw-montreal.cryptostorm.nu
***MISSING***



raw-montreal.cstorm.pw
Name: raw-montreal.cstorm.pw
Addresses: 198.50.119.172
70.38.46.224

raw-frankfurt.cryptostorm.net
Name: raw-frankfurt.cryptostorm.net
Address: 46.165.222.246

raw-frankfurt.cryptostorm.org
Name: raw-frankfurt.cryptostorm.org
Address: 46.165.222.246

raw-frankfurt.cryptostorm.nu
Name: raw-frankfurt.cryptostorm.nu
Address: 46.165.222.246

raw-frankfurt.cstorm.pw
Name: raw-frankfurt.cstorm.pw
Address: 46.165.222.246

raw-iceland.cryptostorm.net
***MISSING***


raw-iceland.cryptostorm.org
Name: raw-iceland.cryptostorm.org
Address: 79.134.255.83

raw-iceland.cryptostorm.nu
***MISSING***



raw-iceland.cstorm.pw
Name: raw-iceland.cstorm.pw
Address: 79.134.255.83

windows-montreal.cryptostorm.net
Name: windows-montreal.cryptostorm.net
Addresses: 198.50.119.171
70.38.46.226

windows-montreal.cryptostorm.org
Name: windows-montreal.cryptostorm.org
Addresses: 198.50.119.171
70.38.46.226

windows-montreal.cryptostorm.nu
***MISSING***


windows-montreal.cstorm.pw
Name: windows-montreal.cstorm.pw
Addresses: 70.38.46.226
198.50.119.171

windows-frankfurt.cryptostorm.net
Name: windows-frankfurt.cryptostorm.net
Address: 46.165.222.207

windows-frankfurt.cryptostorm.org
Name: windows-frankfurt.cryptostorm.org
Address: 46.165.222.207

windows-frankfurt.cryptostorm.nu
Name: windows-frankfurt.cryptostorm.nu
Address: 46.165.222.207

windows-frankfurt.cstorm.pw
Name: windows-frankfurt.cstorm.pw
Address: 46.165.222.207

windows-iceland.cryptostorm.net
Name: windows-iceland.cryptostorm.net
Address: 79.134.255.93

windows-iceland.cryptostorm.org
Name: windows-iceland.cryptostorm.org
Address: 79.134.255.93

windows-iceland.cryptostorm.nu
***MISSING***


windows-iceland.cstorm.pw
Name: windows-iceland.cstorm.pw
Address: 79.134.255.93


These were checked against 8.8.8.8


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

Re: cryptostorm: client config discussions, bugs, requests,

Postby cryptostorm_ops » Sun Jan 12, 2014 5:46 pm

Lignus wrote:Ran some DNS checks, the .nu domain had either not propagated or has not been updated. In addition, it looks like one of the .net ones was overloked:

raw-montreal.cryptostorm.nu
***MISSING***

windows-montreal.cryptostorm.nu
***MISSING***

windows-iceland.cryptostorm.nu
***MISSING***


Excellent work on those - one was still propagating, but the other two had indeed been overlooed in this round of updates. We've not yet moved to a bulk-friendly nameserver service (for a number of reasons, we have avoided doing nameserver & DNS resolution in-house for many years - likely a good topic to discuss at some point in time, here in the forum), and as a result these entries are being manually version-controlled across multiple registrars & TLDs. It's ripe for minor errors, unfortunately, so outside checks are much appreciated.

These were checked against 8.8.8.8


Fair enough. Google's DNS system has become somewhat canonical in recent years, although server-side we do not use them as their fooprint within the United States of NSAmerica is just a bit too impossible to ignore at this point.

raw-iceland.cryptostorm.nu
***MISSING***

raw-iceland.cryptostorm.net
***MISSING***


Officially, there's no "raw-iceland" TLD set currently as there's not yet a dedicated daemon for raw connections on our Icelandic exitnode (reason: additional IPs are still being assigned to the hardware in the datacentre, & current IP allocations are already deployed against Windows & administrative requirements - hope to have that resolved shortly).

We didn't want to give too much of a "false hope" that the raw Iceland subdomains are pointing at properly-instantiated network daemons... when in fact they're simply dumping session handshakes into the Windows daemon for the time being (note: some folks have tweaked their raw configs to enable connects to that daemon, which is something we've no problem with but which we can't explicitly recommend as it's a rather fiddly process & will be resolved with extra IPs shortly).

If you notice any other anomalies in the TLD mappings, please do let us know. We're working upfront to ensure a broad & diverse sweep of registrars & TLDs within our resolution framework, so that any outage or censorship of a given domain and/or registrar is transparently handled via the existing, already-pushed redundancy within our <connections> elements.

Thank you,

~ cryptostorm_ops

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm: client config discussions, bugs, requests,

Postby Pattern_Juggled » Sun Jan 12, 2014 6:26 pm

Looks like all of the current (version 1.2) "raw"/Linux client config files are now pushed to production and available in conf.cryptostorm.org.

I've been part of the testing team for these new 1.2 revs, and I can confirm firsthand that I've seen successful connects & clean client and server-side error logs for them, across clusters and exitnodes. I can also confirm, personally, that I'll be entirely un-surprised if there's somehow still some bugs lurking herein - despite best efforts to squash them in advance. If you notice any such, please do let us know & we'll get 'em resolved right away. Certainly our goal is zero bugs with these releases... but anyone who thinks that's going to be a 100% guarantee is probably being a bit optimistic about how the universe actually works. :-P

Iceland is not currently part of the default rotation for raw connections - we're awaiting additional IP allocations to make that happen. Should be in the very near future.

With all this version-control madness (hopefully) now behind us, we're completely free to spin up support for dedicated instances to support iOS, Android, router-specific kernels... whatever is needed. So if you've got an idea up your sleeve that'd require server-side customization of session parameters, we're now able to do exactly that if the situation looks interesting. Top on that list is an iOS-custom striping across exitnodes... something we've been working on behind the scenes for a few months with the assistance of several really talented cryptostorm members.

Cheers! :-)
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f


Lignus
Posts: 33
Joined: Sat Nov 02, 2013 1:26 am

Re: cryptostorm: client config discussions, bugs, requests,

Postby Lignus » Sun Jan 12, 2014 8:04 pm

cryptostorm_ops wrote:
These were checked against 8.8.8.8

Fair enough. Google's DNS system has become somewhat canonical in recent years, although server-side we do not use them as their fooprint within the United States of NSAmerica is just a bit too impossible to ignore at this point.


Neither do I, at least not since I switched over to using CS. I do use 8.8.8.8 as I was explicitly specifying a DNS server for consistency and I can remember. Besides, like you said, it is the current gold standard.

list dhcp_option '6,198.100.146.51,213.73.91.35,194.150.168.168,80.237.196.2,185.19.105.14,69.164.196.21'
:D

User avatar

marzametal
Posts: 498
Joined: Mon Aug 05, 2013 11:39 am

Re: windows-frankfurt-cryptostorm.net

Postby marzametal » Mon Jan 13, 2014 6:49 am

cryptostorm_ops wrote:
marzametal wrote:Congrats on all the work behind the scenes!
I would like to mention that I had no internet response when using "windows-frankfurt.cryptostorm.net". I switched to the Iceland one and all was swell...


Thanks for the bug report - we did find an erroneous A record mapping that had been propagated. That has been resolved, and this mapping - windows-frankfurt.cryptostorm.net - should be resolving to the correct IP/instance within the Frankfurt exitnode cluster.

If you have a chance to test that out, please let us know what your results are so that we can be sure we've flushed the incorrect mapping.

Thank you,

~ cryptostorm_ops


Hi Ops...
I just swapped over the mapping entry in the .conf file to Frankfurt and logged onto the darknet. All is swell now. Fully functional! Thanks for everything and all the best!


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

full deployment of "raw" 1.3 client framework

Postby cryptostorm_ops » Mon Jan 27, 2014 6:50 pm

Please note that all of the client configuration files for Linux/"raw" connections have now been upgraded to 1.3 versioning. This includes both cluster-specific connection profiles, as well as the locked/dynamic network-wide meta-profiles.

They have been, per standard, posted to the canonical conf.cryptostorm.org resource in order to be available for production deployment.

Anyone using earlier versions of the configs is strongly encouraged to update. We have done our best to support backwards-compatability, but it has not been possible to provide full coverage of all prior config versions without crippling performance improvements. As such, use of earlier configs is likely to result in sporadic, unreliable network connectivity.

We do not expect to be deploying substantive changes to these Linux/"raw" 1.3 configuration profiles for some time; major functionality updating has been compressed into this one, larger break with prior versioning. It has not been convenient for network members, and we regret that - however, in doing so, we've cleared a path forward with no visible roadblocks looming ahead.

Thank you,

~ cryptostorm_ops

User avatar

cryptostorm_support
ForumHelper
Posts: 296
Joined: Sat Jan 26, 2013 4:31 am
Contact:

Re: client config for cryptostorm: general discussion & bugh

Postby cryptostorm_support » Mon Feb 17, 2014 4:22 pm

I've moved a post regarding the widget, by Asklepios, over to the widget support thread so it's easier to keep track of things - it's not gone, or deleted... just moved to a cozy new home in the support forum! :-)
cryptostorm_support shared support team forum account
PLEASE DON'T SEND PRIVATE MESSAGES with support questions!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm


pinetop
Posts: 3
Joined: Sun Mar 02, 2014 6:04 am

Re: client config for cryptostorm: general discussion & bugh

Postby pinetop » Sun Mar 02, 2014 6:33 am

I am starting to think that I am crazy... When I try to use the widget this is the error i get.
When I first started this TAP didnt even install, now it is installed and I am getting same error.

Sat Mar 01 19:31:02 2014 us=992590 UDPv4 WRITE [14] to [AF_INET]192.96.201.86:443: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0

I have also tried using OpenVPN and the config file. and it asks for a user/pass im at a loss


docwho

Re: client config for cryptostorm: general discussion & bugh

Postby docwho » Tue Sep 30, 2014 1:11 am

Why do you define ns-cert-type instead of tls-remote? Its my understanding that ns-cert-type is depreciated.
Why do you use tls-client when your using client? It seems like your over complicating things.


Return to “cryptostorm in-depth: announcements, how it works, what it is”

Who is online

Users browsing this forum: Bing [Bot] and 1 guest

Login