Ξ 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 Ξ
Ξ We've updated our CA certificate. All members need to be using the latest ones by Dec 22. See this page for more infoΞ

TCP-based cstorm sessions, & "port striping" techniques

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!

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

TCP-based cstorm sessions, & "port striping" techniques

Postby cryptostorm_ops » Tue Jan 21, 2014 1:06 pm

note: this is an old post, & the config settings in it are not valid currently! However, with the deployment of our "port striping" framework (more on that shortly), this subject is now both relevant and much more interesting. As such, we're bumping this thread back up, & keeping these older posts for background & informational purposes, as well ~admin.


As there have been a number of instances in which cryptostorm members are facing local network firewalling of wide swaths of UDP traffic, we have been working on a TCP-based daemon framework to enable connections in this type of local networking environment. This is a generic version of our 1.2 revision configuration framework itself, stripped-down to its cryptographic essentials in order to provide the widest possible range of connect abilities without losing any of our essential security components. It should work for most OS flavours, and even for the widget with a bit of tweaking of the underlying widget config file settings.

note: this is a beta distribution, as it has not received extensive in-house staff testing - we are releasing it in order to receive further community input and assistance in the testing. If you use it, please post your results in this thread so that we are able to improve and track this connection framework.

We do not recommend that members use TCP-based sessions unless it is absolutely necessary, and we are not engaging in the same level of intensive performance-tuning of these TCP-session instances as we do our mainline, UDP-based frameworks. This is because TCP over TCP is always going to be severely performance constrained; this is inherent to the structural underpinnings of such a network topology. More details can be found in this reference thread.

Finally, we are working on additional firewall/DPI transcendence techniques. In the short term, this involves routing of UDP packets via protocol masquerading. Medium-term, we are working with the Dust protocol to implement a broad-range, highly robust, extremely well-designed protocol obfuscation framework that is proven effective in the wild against essentially every known firewalling / filtering / DPI-based tool on the market today.

Code: Select all

[root@bruno tcpvpn]# cat tcpvpn.conf
# cryptostorm_server version 1.2 config - TCP sessions
# beta version of deprecated TCP-over-TCP legacy support daemon
# discussion & details in http://serverconf.cryptostorm.org

daemon
local 174.142.78.194
port 443
proto tcp
dev tun

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

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

# tun-ipv6
# we aren't yet supporting IPv6 as it's not supported fully by OpenVPN & OpenSSL
# several active dev projects are at work on this & we are following them regularly

persist-key
push "persist-key"
# not essential, but smooths SIGHUPs of individual openvpn processes as in new conf loads

persist-tun
push "persist-tun"
# retain tun instantiation client-side during reconnects, to smooth process

fast-io
# experimental directive in OpenVPN 2.3.2 - testing for performance gains on openvpn
# optimize TUN/TAP/UDP I/O writes by avoiding a call to poll/epoll/select prior...
# to the write operation

ca /etc/tcpvpn/easy-rsa/keys/ca.crt
cert /etc/tcpvpn/easy-rsa/keys/server.crt
key /etc/tcpvpn/easy-rsa/keys/server.key
dh /etc/tcpvpn/easy-rsa/keys/dh2048.pem
# standard PKI/CA asymmetric key materials storage
# we manually generate & manage all key materials firsthand via cryptographic best practices

script-security 2
auth-user-pass-verify /etc/tcpvpn/auth.sh via-file
client-connect /etc/tcpvpn/session_up.sh
client-disconnect /etc/tcpvpn/session_down.sh
# custom-generated script hooks into our token auth system

tmp-dir /tmp
# manually set temp directory, to ensure active swap over-writes temp data consistently

topology subnet
server 10.22.0.0 255.255.0.0
# internal, non-routed subnet topology for ephemeral network member assignment
# essentially, an internal DHCP framework for client-to-exitnode tunnelized packet transit

float
# allows client to change IP, as with DHCP re-lease, & retain secure session...
# if HMAC continues to validate

push "redirect-gateway def1"
push "redirect-gateway bypass-dhcp"
# directives to allow clients to re-lease local DHCP outside of secure session via...
# LAN route details & metrics

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

# these below are our selected DNS services for within-network canonical resolution
push "dhcp-option DNS 198.100.146.51"
push "dhcp-option DNS 76.74.205.228"
# OpenNICproject.org, Canuck-optimised :-)
push "dhcp-option DNS 91.191.136.152"
# Telecomix is.gd/jj4IER
push "dhcp-option DNS 213.73.91.35"
# CCC http://is.gd/eC4apk

duplicate-cn
client-cert-not-required
# we do not use certs to uniquely identify connected members...
# doing so is a serious security failure and needlessly endangers anonymity on-net

keepalive 20 60
# retains active sessions with connected members during temporary traffic lulls

max-clients 300
# caps the number of simultaneous connections to a specific exitnode machine

# fragment 1400
# mssfix 1400
# tunes the UDP session by fragmenting below the MTU upper bound
# much undocumented/unexpected behaviours result from these parameters, beware!
# we routinely test & refine these parameters, in-house, for best performance
# they cannot be 'pushed' to clients, as are required a priori for control channel setup

reneg-sec 1200
# cycle symmetric keys via tls renegotiation every 20 minutes
# an essential fallback to TLS-based 'perfect forward secrecy' via Diffie Hellman keygen

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 cipher libraries offer our choice...
# AES-GCM is looking good currently

tls-server
key-method 2
# specification of entropy sources (PRNG) used in generation of key materials

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

tls-exit
# exit on TLS negotiation failure

# comp-lzo no
# push "comp-lzo no"
# we are working towards removal of this from the network...
# but it sneaks in via client-side prefs

user nobody
group nobody
# nogroup on some distros

tran-window 256
# amount of overlap between old and new TLS control channel session keys allowed
# default is 3600, which is way too long to work with PFS & 1200 2nd key renegotiations

verb 5
mute 2
status /var/log/tcpvpn-status.log
log /var/log/tcpvpn.log
# rotating error & connection log parameters - cycle w/ each connection
# used to track packet-level errors within secure sessions
# does not retain any session-level detail - also wipes via regular session cycle


vibert
Posts: 9
Joined: Wed Sep 04, 2013 2:14 pm

Re: cryptostorm: TCP-based fallback for firewalled local net

Postby vibert » Wed Jan 22, 2014 4:16 am

Hello, I had to make some configuration changes to connect with the Cryptostorm Widget:

Comment "replay-window" (it is not a valid TCP option)

Modify: auth-user-pass to: auth-user-pass client.dat

Added:
cert clientgeneric.crt
key clientgeneric.key

I am on a "decent" environment right now. (UDP not blocked) I will report what happens on a DPI environment soon. Hopefully this works for now, but looking forward to see new solutions like Dust.

I'll be reporting findings soon.

User avatar

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

TCP widget & Dust/Haskell

Postby Pattern_Juggled » Wed Jan 22, 2014 11:59 am

vibert wrote:Hello, I had to make some configuration changes to connect with the Cryptostorm Widget:

Comment "replay-window" (it is not a valid TCP option)


That's an excellent catch - obviously (in hindsight) not a relevant parameter for TCP sessions. At some point, we'll want to go back through all the less common parameter options for various TCP-specific opportunities for session performance tuning opportunities. It's been so long since I've looked at those, having been on the project team that shifted to production UDP-based secure network sessions back in 2008 (when TCP was the default for such things), I've become rusty in my recollections. Although there's not been as much focus on TCP session tuning by the OpenVPN project in recent years, there's still a host of deprecated capabilities hidden in there... just have to go dig 'em back up.

From memory, I believe there's opportunities for minimization of the TCP-over-TCP shortcomings via sysctl-layer parameter synch with the userland-layer settings of OpenVPN... but, again, I need to refresh my own recollections of such at the detailled layer before I can provide much useful advice.

Modify: auth-user-pass to: auth-user-pass client.dat

Added:
cert clientgeneric.crt
key clientgeneric.key

I am on a "decent" environment right now. (UDP not blocked) I will report what happens on a DPI environment soon. Hopefully this works for now, but looking forward to see new solutions like Dust.

I'll be reporting findings soon.


If there's demand for a TCP-based Widget build based on your work in this port, we'll be happy to custom-roll a compile for use in these scenarios. I'm going to recommend we hold off until we've got some more data points from your testing... but it's quite reasonable to do.

We did a bit of work on the Dust framework yesterday - if you happen to know anyone with dirt-under-the-fingernails experience in Haskell-based toolsets, we'd love to have someone to share their expertise as we work through the integration process. To be clear, we're not putting extensive resources into it just yet - core network tuning and stabilisation comes first and foremost, always, and until that's well and truly in hand the next-tier enhancements are of secondary priority for the project team.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f


vibert
Posts: 9
Joined: Wed Sep 04, 2013 2:14 pm

Re: TCP widget & Dust/Haskell

Postby vibert » Wed Jan 22, 2014 9:38 pm

Preliminary findings:

- There seems to be a problem with remote-random with Cryptostorm Widget. NU and PW domain names aren't yet available which seems to hang the widget at point of no return. (Or variable network conditions, domain blocking) Still yet to continue checking that.

- As I really needed to get going I configured a raw OpenVPN 2.3.2 with the configuration. It took a while cycling in the domains but it connected after all. (Seems to be a good workaround to multiple configs also) Widget/Raw OpenVPN one click connect

- Bandwidth was getting maxed, latency seemed to be affected but it could have been bad network conditions as well.

Pattern_Juggled wrote:
That's an excellent catch - obviously (in hindsight) not a relevant parameter for TCP sessions. At some point, we'll want to go back through all the less common parameter options for various TCP-specific opportunities for session performance tuning opportunities. It's been so long since I've looked at those, having been on the project team that shifted to production UDP-based secure network sessions back in 2008 (when TCP was the default for such things), I've become rusty in my recollections. Although there's not been as much focus on TCP session tuning by the OpenVPN project in recent years, there's still a host of deprecated capabilities hidden in there... just have to go dig 'em back up.

From memory, I believe there's opportunities for minimization of the TCP-over-TCP shortcomings via sysctl-layer parameter synch with the userland-layer settings of OpenVPN... but, again, I need to refresh my own recollections of such at the detailled layer before I can provide much useful advice.



I will take a look on the web to see if I can find out something interesting.


Pattern_Juggled wrote:
If there's demand for a TCP-based Widget build based on your work in this port, we'll be happy to custom-roll a compile for use in these scenarios. I'm going to recommend we hold off until we've got some more data points from your testing... but it's quite reasonable to do.

We did a bit of work on the Dust framework yesterday - if you happen to know anyone with dirt-under-the-fingernails experience in Haskell-based toolsets, we'd love to have someone to share their expertise as we work through the integration process. To be clear, we're not putting extensive resources into it just yet - core network tuning and stabilisation comes first and foremost, always, and until that's well and truly in hand the next-tier enhancements are of secondary priority for the project team.


Testing is going to definitely become common at my end. If you can recall OpenVPN parameters let me know for testing.

I am definitely excited for protocol obfuscation. (Wondering if it might cause much more heavy resources at your end, though so it might be something not enabled by default) I am glad you are still working on network tuning and stabilization but the future seems really exciting.


vibert
Posts: 9
Joined: Wed Sep 04, 2013 2:14 pm

Re: cryptostorm: TCP-based fallback for firewalled local net

Postby vibert » Fri Jan 24, 2014 7:12 am

Bad news: This is getting blocked now. I confirmed with a mobile connection that my TCP config is working at the moment. My connection is getting reset. I am certain there is nobody administrating it, but the DPI appliance is very agressive. I do know which hardware is being used if that could be of use.

OpenVPN log provided:

Code: Select all

Thu Jan 23 18:10:38 2014 Current Parameter Settings:
Thu Jan 23 18:10:38 2014   config = 'vpn.ovpn'
Thu Jan 23 18:10:38 2014   mode = 0
Thu Jan 23 18:10:38 2014 NOTE: --mute triggered...
Thu Jan 23 18:10:38 2014 382 variation(s) on previous 3 message(s) suppressed by --mute
Thu Jan 23 18:10:38 2014 OpenVPN 2.3.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013
Thu Jan 23 18:10:38 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Thu Jan 23 18:10:38 2014 Need hold release from management interface, waiting...
Thu Jan 23 18:10:38 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Thu Jan 23 18:10:39 2014 MANAGEMENT: CMD 'state on'
Thu Jan 23 18:10:39 2014 MANAGEMENT: CMD 'log all on'
Thu Jan 23 18:10:39 2014 MANAGEMENT: CMD 'hold off'
Thu Jan 23 18:10:39 2014 NOTE: --mute triggered...
Thu Jan 23 18:10:39 2014 1 variation(s) on previous 3 message(s) suppressed by --mute
Thu Jan 23 18:10:39 2014 Control Channel MTU parms [ L:1603 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu Jan 23 18:10:39 2014 Socket Buffers: R=[65536->65536] S=[65536->65536]
Thu Jan 23 18:10:39 2014 MANAGEMENT: >STATE:1390525839,RESOLVE,,,
Thu Jan 23 18:10:39 2014 Data Channel MTU parms [ L:1603 D:1450 EF:103 EB:4 ET:0 EL:0 ]
Thu Jan 23 18:10:39 2014 Local Options String: 'V4,dev-type tun,link-mtu 1603,tun-mtu 1500,proto TCPv4_CLIENT,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
Thu Jan 23 18:10:39 2014 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1603,tun-mtu 1500,proto TCPv4_SERVER,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server'
Thu Jan 23 18:10:39 2014 Local Options hash (VER=V4): '17c82e93'
Thu Jan 23 18:10:39 2014 Expected Remote Options hash (VER=V4): '757adecc'
Thu Jan 23 18:10:39 2014 Attempting to establish TCP connection with [AF_INET]174.142.78.194:443
Thu Jan 23 18:10:39 2014 MANAGEMENT: >STATE:1390525839,TCP_CONNECT,,,
Thu Jan 23 18:10:39 2014 TCP connection established with [AF_INET]174.142.78.194:443
Thu Jan 23 18:10:39 2014 TCPv4_CLIENT link local: [undef]
Thu Jan 23 18:10:39 2014 TCPv4_CLIENT link remote: [AF_INET]174.142.78.194:443
Thu Jan 23 18:10:39 2014 MANAGEMENT: >STATE:1390525839,WAIT,,,
Thu Jan 23 18:10:39 2014 TCPv4_CLIENT WRITE [14] to [AF_INET]174.142.78.194:443: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Jan 23 18:10:39 2014 Connection reset, restarting [-1]
Thu Jan 23 18:10:39 2014 TCP/UDP: Closing socket
Thu Jan 23 18:10:39 2014 SIGUSR1[soft,connection-reset] received, process restarting
Thu Jan 23 18:10:39 2014 MANAGEMENT: >STATE:1390525839,RECONNECTING,connection-reset,,
Thu Jan 23 18:10:39 2014 Restart pause, 5 second(s)
Thu Jan 23 18:10:44 2014 Control Channel MTU parms [ L:1603 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu Jan 23 18:10:44 2014 Socket Buffers: R=[65536->65536] S=[65536->65536]
Thu Jan 23 18:10:44 2014 MANAGEMENT: >STATE:1390525844,RESOLVE,,,
Thu Jan 23 18:10:44 2014 Data Channel MTU parms [ L:1603 D:1450 EF:103 EB:4 ET:0 EL:0 ]
Thu Jan 23 18:10:44 2014 Local Options String: 'V4,dev-type tun,link-mtu 1603,tun-mtu 1500,proto TCPv4_CLIENT,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
Thu Jan 23 18:10:44 2014 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1603,tun-mtu 1500,proto TCPv4_SERVER,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server'
Thu Jan 23 18:10:44 2014 Local Options hash (VER=V4): '17c82e93'
Thu Jan 23 18:10:44 2014 Expected Remote Options hash (VER=V4): '757adecc'
Thu Jan 23 18:10:44 2014 Attempting to establish TCP connection with [AF_INET]174.142.78.194:443
Thu Jan 23 18:10:44 2014 MANAGEMENT: >STATE:1390525844,TCP_CONNECT,,,
Thu Jan 23 18:10:44 2014 TCP connection established with [AF_INET]174.142.78.194:443
Thu Jan 23 18:10:44 2014 TCPv4_CLIENT link local: [undef]
Thu Jan 23 18:10:44 2014 TCPv4_CLIENT link remote: [AF_INET]174.142.78.194:443
Thu Jan 23 18:10:44 2014 MANAGEMENT: >STATE:1390525844,WAIT,,,
Thu Jan 23 18:10:44 2014 TCPv4_CLIENT WRITE [14] to [AF_INET]174.142.78.194:443: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Jan 23 18:10:44 2014 Connection reset, restarting [-1]
Thu Jan 23 18:10:44 2014 TCP/UDP: Closing socket
Thu Jan 23 18:10:44 2014 SIGUSR1[soft,connection-reset] received, process restarting
Thu Jan 23 18:10:44 2014 MANAGEMENT: >STATE:1390525844,RECONNECTING,connection-reset,,
Thu Jan 23 18:10:44 2014 Restart pause, 5 second(s)
Thu Jan 23 18:10:49 2014 Control Channel MTU parms [ L:1603 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu Jan 23 18:10:49 2014 Socket Buffers: R=[65536->65536] S=[65536->65536]
Thu Jan 23 18:10:49 2014 MANAGEMENT: >STATE:1390525849,RESOLVE,,,
Thu Jan 23 18:10:50 2014 Data Channel MTU parms [ L:1603 D:1450 EF:103 EB:4 ET:0 EL:0 ]
Thu Jan 23 18:10:50 2014 Local Options String: 'V4,dev-type tun,link-mtu 1603,tun-mtu 1500,proto TCPv4_CLIENT,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
Thu Jan 23 18:10:50 2014 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1603,tun-mtu 1500,proto TCPv4_SERVER,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server'
Thu Jan 23 18:10:50 2014 Local Options hash (VER=V4): '17c82e93'
Thu Jan 23 18:10:50 2014 Expected Remote Options hash (VER=V4): '757adecc'
Thu Jan 23 18:10:50 2014 Attempting to establish TCP connection with [AF_INET]174.142.78.194:443
Thu Jan 23 18:10:50 2014 MANAGEMENT: >STATE:1390525850,TCP_CONNECT,,,
Thu Jan 23 18:10:51 2014 TCP connection established with [AF_INET]174.142.78.194:443
Thu Jan 23 18:10:51 2014 TCPv4_CLIENT link local: [undef]
Thu Jan 23 18:10:51 2014 TCPv4_CLIENT link remote: [AF_INET]174.142.78.194:443
Thu Jan 23 18:10:51 2014 MANAGEMENT: >STATE:1390525851,WAIT,,,
Thu Jan 23 18:10:51 2014 TCPv4_CLIENT WRITE [14] to [AF_INET]174.142.78.194:443: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Jan 23 18:10:51 2014 Connection reset, restarting [-1]
Thu Jan 23 18:10:51 2014 TCP/UDP: Closing socket
Thu Jan 23 18:10:51 2014 SIGUSR1[soft,connection-reset] received, process restarting
Thu Jan 23 18:10:51 2014 MANAGEMENT: >STATE:1390525851,RECONNECTING,connection-reset,,
Thu Jan 23 18:10:51 2014 Restart pause, 5 second(s)

User avatar

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

Re: cryptostorm: TCP-based fallback for firewalled local net

Postby cryptostorm_team » Fri Jan 24, 2014 6:04 pm

vibert wrote:Bad news: This is getting blocked now. I confirmed with a mobile connection that my TCP config is working at the moment. My connection is getting reset. I am certain there is nobody administrating it, but the DPI appliance is very agressive. I do know which hardware is being used if that could be of use.


Yes - any and all details about the DPI framework you're facing will be extremely helpful to our development team in terms of planning future protocol obfuscation techniques based on in-the-wild member scenarios.

Our team has fairly extensive experience with such matters, and in the past we've custom-rolled solutions for specific DPI environments as needed; an example was our support for activists during Iran's "Green Revolution" in 2009, during which we custom-coded DPI-resistant client builds & distributed hundreds of free accounts to frontline participants in the protests & organizational efforts behind the scenes.

Thanks!

    ~ 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: support@cryptostorm.is
live chat support: #cryptostorm


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

TLDs & protocol hardening

Postby cryptostorm_ops » Fri Jan 24, 2014 6:26 pm

vibert wrote:- There seems to be a problem with remote-random with Cryptostorm Widget. NU and PW domain names aren't yet available which seems to hang the widget at point of no return. (Or variable network conditions, domain blocking) Still yet to continue checking that.


We've added the cryptostorm.nu subhost mapping, which had been neglected. However, we've also confirmed that the cstorm.pw mapping was included accurately in the original production push, which likely means that DNS resolution for that TLD isn't being supported via your chosen out-of-tunnel DNS providers. This is a somewhat novel TLD, admittedly, but not so far out of conventional parameters that lookups should prove systematically difficult. That said, it's a fallback TLD and if it fails to resolve, client sessions should (in theory) cycle forward to the next <connection> profile.

The current widget build (0.92) does not include redundant TLD <connection> profiles, although it is possible some network members have built them in via edits to the .conf client-side (which is entirely acceptable). Our 1.0 widget build does include TLD redundancy, as is seen already in the "raw" configuration settings available.

I am definitely excited for protocol obfuscation. (Wondering if it might cause much more heavy resources at your end, though so it might be something not enabled by default) I am glad you are still working on network tuning and stabilization but the future seems really exciting.


On a philosophical level, we are somewhat strongly opposed to "tiered" security settings for cryptostorm sessions. Creating a system in which members need to make tedious choices amoungst ambiguous, technical security options does not engender strong network-wide security for all members. Instead, our approach is to deploy hardened security for all sessions - leaving member configuration choices to items that don't directly impact operational security levels.

That said, protocol obfuscation isn't likely to prove sufficiently resource intensive to require such tradeoffs, in any case. In the event such matters require additional resources, our approach is to provide such resources via additional server-side capacity... something we've done from the beginning in our support of heavily hardened cipher suite selections, despite the compute-intensive nature of these deployed cryptographic protections.

Thank you,

~ cryptostorm_ops


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

Who is online

Users browsing this forum: No registered users and 10 guests

Login