cryptostorm's community forum

Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

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!

Just to ensure everyone that I (df) didn't fall off the face of the earth, I wanted to give everyone an update on what's coming in v3 of the widget. I wanted to be done with this version on the 1st of 2016, but I kept adding features and fixing new & old bugs etc. that I had to push the release date further.

The current functional features are:DNSCrypt support!
Now your DNS queries will be hidden from your ISP before you even connect to CS, so unless they're keeping track of all of our DNSCrypt/DeepDNS IPs (which is why you can choose a non-CS DNSCrypt server in v3), they won't even know you're connecting to CS.

Another feature is updates via the VPN:
Before, updates were accomplished simply by grabbing https://cryptostorm.nu/latest.txt and checking if the version listed in that file after "LATEST:" is greater than the version you're using. If latest.txt says you're using an old version, a lazy `start https://cryptostorm.nu/setup.exe` was executed, which means your default browser would goto https://cryptostorm.nu/setup.exe. This method sucks for one main reason: If you can't reach cryptostorm.nu, you can't get updates. So if your ISP is blocking requests to cryptostorm.nu, or cryptostorm.nu goes down for some reason, no updates for you.

For v3, I've decided the best alternative method to this is implementing a server-side dummy interface that has a webserver listening on http://10.31.33.7/ that can only be accessed if you're connected to the VPN. On that webserver is the same latest.txt. That means that if you can get on the VPN, you'll be able to get that latest.txt file using the VPN's tunnel instead of relying on plain HTTPs (unless Apache dies on that particular server, which is highly unlikely thanks to a minimal setup + deamontools).

Adding onto the above feature is automatic updates of the OpenSSL and OpenVPN files that power the widget. It's still being tested, but the idea is that when, after connected to CS, the widget downloads http://10.31.33.7/latest.txt, it not only includes the latest widget version, but also the latest OpenSSL and OpenVPN (and their library/.dll) versions, then downloads their updates if they're newer than the versions the widget is currently using. The most obvious problem I could see with this idea is that if someone somehow managed to hack into a node and uploads malicious OpenSSL/OpenVPN binaries to this http://10.31.33.7/ webserver, they could gain access to the client's system. So to prevent that, asymmetrical cryptography is used. The widget downloads the updated file to a temp directory, then it downloads that file's sha512 signature. Included with the v3 widget is the public key that will be used to verify the downloaded files signature (along with ossl.exe, a win32 precompiled openssl.exe), as seen in this code:

Since the private key used to sign these binaries are only on my personal system, hacking into the node won't give you the ability to modify these files without the v3 widget bitching and whining about it.

I'm thinking this would also be a good method for updating the widget without requiring the user to reinstall via the setup.exe each time too (i.e., the widget just automagically downloads [and verifies] client.exe for the future versions).

The other major feature is also a bugfix. If the widget is left running forever, eventually the system may enter a suspend/hibernate state. Now there's code that'll detect such an event, and disconnect the widget since all other internet related features of Windows will be disabled during this period anyways, then the widget will reconnect when the system wakes up. The problem before was that when you resume from suspend/hibernate, the widget would complain that it couldn't resolve anything, because the v2.22 widget told the OS to use the DeepDNS IPs for DNS, but on un-suspend/hibernate, those IPs are no longer accessible. So with v3, it'll detect that power state and adjust accordingly.

The rest are mainly minor bugfixes:

If you click the systray icon and the widget main window is already opened, but minimized or not in focus, nothing happens. Now it'll restore focus to the widget.

This one's a bug I'm considering a feature: user connects like normal, goes to options, changes DNSCrypt server, goes back, now they're using 127.0.0.1 (DNSCrypt) instead of the pushed DeepDNS server.
Wireshark says even by doing that the DNS still goes thru the VPN. So I'm not fixing this mistake

Fixed an old bug where if the node list can't be grabbed from https://cryptostorm.nu/nodelist.txt, the drop down node list in the widget would be emptied out (I just needed to undefine a buffer before a certain function).

Fixed an odd window render bug where the if the splash screen is disabled the default Tcl test window would show up before the main widget screen for about a half a second. Not really that important, but looks sloppy. Fixed now.

Fixed that occasional bug where some users get an Options window that's a square (which hides buttons etc.) instead of the intended rectangle.

Fixed the bug where if the widget can't update the node list, any further attempts to try to do so would fail (a buffer needed to be cleared).

Even more minor GUI updates include: Changing the text on the main window to code that mimics a hyperlink, so you can click on those text links. Also, since Tk's GIF capabilities are dumb/non-functional, I created some code that'll sorta mimic the visual aspects of a GIF so the world icon looks more animated

ANYWHO
I'm still working on the "update while on CS" code, and I'm debating on whether or not to push the release of v3 even further just so obfsproxy support is included. I dunno yet, if that ends up not taking alot of time to implement, I'll do that. If I find a bunch of problems in implementing obfsproxy, I'll save that for v3.1

from that github page - "Functionality of this plugin is integrated into OpenVPN 2.3.9, just use --block-outside-dns". v3 will use the latest OpenVPN and block-outside-dns :-P
in my tests it seemed to be working, but i haven't yet tested v3 on win10. if it's still leaking, i'll throw that .dll together with the widget.

I put the *.dll in the bin directory them modified the ovpn conf to include "plugin fix-dns-leak-64.dll" and them it works just fine with Windows 10 (I'm starting to feel sorry having upgraded the laptop of my wife from Windows 7 to 10)

This Windows 10 is really a fu**ing spyware!

My really good recommandation for anything VPN related when using Windows 10 is to use a Router with OpenVPN, that way there are no leaks since Windows doesn't see the "real ip" never...

So, I've been messing around with "--block-outside-dns" since the DLL files don't work for me. I think I figured out the problem. It's kind of silly. openvpn-gui.exe doesn't accept the argument --block-outside-dns, but openvpn.exe itself does.

Doesn't that just mean that we could make it a standard .ovpn configuration option? Just put "block-outside-dns" as an option under client?

Edit: Yep, that works. It causes the following line to magically appear in the log:

Fri Feb 26 14:43:54 2016 Blocking outside DNS

It works! You just use the command as an argument in the .ovpn file, not when calling the GUI executable in the first place.

The option worked fine in my widget tests, but I noticed that even when it's enabled win8.1 will still leak IPv6 DNS since there's really no way to turn that off without something like those .dll's (which I haven't tested yet).

df wrote:The option worked fine in my widget tests, but I noticed that even when it's enabled win8.1 will still leak IPv6 DNS since there's really no way to turn that off without something like those .dll's (which I haven't tested yet).

Yeah you're right, only with the option enable it leaks, but with the dll it came out beautiful (I still don't worry about that when I'm home since, has you can see, I run several instances of dnscrypt-proxy in my router )

Tested. Works w/ problems. Great work.
For dnscrypt, i already used it for my dns like default with Simple DNScrypt, but the official dnscrypt csv list https://download.dnscrypt.org/dnscrypt-proxy/ has less crypto server, i am waiting to see all the others.

2 thoughs:

1: the list here https://cryptostorm.nu/nodelist.txt is different for one node, there is not voodoo server; i ask this because when i try to update nodes in v3 button stucks, seems like blocked and nothing happened. I need to close widget and open it again;

2: Voodoo Isle of Man:IMN is not accessible from windows? What mean IMN? I would like to access to this "Isle of Man", seems "cool".

Note that this version linked to above is really, really alpha... nothing wrong with alpha - but remember that it's not even officially beta yet!

(having a wider member pool playing around with the alpha version can - in theory - help to highlight areas where we might not have even been watching to closely so that we can rethink those decisions, more so than actually pinning down pre-production bugs or fine-tuning which will still require substantial beta testing; so, for those alpha testers giving things a try, please keep your view broad and wide, in terms of feeling confident in providing feedbsck that expands past the usual "here's a specific bug report, let's get it squashed"... if you have such comments to make, of course)

There's an enormous amount of expertise and experience that df has invested in this new widget version - and, without beating around the bush, the widget has really become an expression of his dedication to cstorm and to creating a Windows-based application that's far beyond basic expectations of what a "VPN service" client program does.

As with many great designs, much of what he's given to us in the new widget comes in the way of things that aren't there, and especially things that aren't visible. Knowing hat not to do can be the ultimate expression of mastery, and he's avoided whole classes of dead-ends, faulty assumptions, broken design models, and coding errors overall. On top, he's provided a lifetime's knowledge of how real attackers work in the real world - using that knowledge to harden this code in a way few consumer-grade security technologies will ever match.

When we released the version 2 widget "Sexy Narwhal" a few years back, the whole team went into an obsessive, iterative cycle of fine-tuning and bughunting that went on for weeks. We had community help, of course... but back then cstorm was a smaller network, and all of us could much more comfortably shun other obligations to eat, breathe, sleep, and dream the widget until it was ready for release. That obsessive attention shows in the Narwhal; it's stood the test of time enormously well, and remains a brilliant piece of security engineering (in my humble - but not disinterested - opinion). It's been polished here and there since then, as can be seen in the Narwhal thread here... but at core, the Narwhal has held its own and still does great work.

This presents a conundrum with the new widget3 (which has been codenamed, internally, "Black Dolphin" since ages ago - but may well end up with a more conventional name upon release... or not?). Do we seek to carve out that kind of obsessive focus-time on the part of the team, to take the Dolphin into its final beta version? Or do we do more of a "rolling beta" kind of process, reaching deeper into the community to help with final refinements and bughunting? The ultimate decision on that philosophical issue is really df's - this is his artistry at play here, and it's his to steer at the deeper levels.

Perhaps that's for the best, as I'm not personally sure the right path forward on this. Ever the obsessive, I lust for that total-focus phase to get this Dolphin widget to its finest form before release... but I know that kind of focus isn't really aligned with cstorm today - which has lots of moving parts, a broader and more diverse team, and... just alot more of everything, basically

There's also two big elephants standing in the corner of the room, in terms of the Dolphin widget: voodoo, and "tokens2" (which has no link, as it's managed to remain firmly behind the scenes thus far). Both are big, hairy, important, fascinating extensions and improvements to cstorm's core model. Both are far along in the development phase - but far from being ready for production at full-network scale. Both will take a bit more refinement, technologically, before they go into widespread deployment... and both involve thorny, challenging questions wrt business model, revenue, reverse compatability, and overall direction for the project moving forward.

Which is to say: getting all that stuff pinned down quickly, so that the Black Dolphin widget (that's how I think of it, anyhow) can get into widespread deployment, isn't going to happen. Not quickly, in the sense of "days, not weeks" - it's just not reasonable. So if a decision is made to integrate voodoo and tokens2 into the new widget (the two components also intertwine with each other, so they basically come as a basket, together), it'll delay the release of the widget. That's reality.

However... if they aren't included, it's likely voodoo/tokens2 will get pushed back, time-wise, before they're really publicly available. Which would be a shame, as they are (in my humble but strongly-felt opinion) the future of cstorm. Delaying them has costs, and misses opportunity windows, and means they aren't themselves being improved and fine-tuned as can only really happen once a technology gets into wider distribution and gets kicked around by a passionate community like that surrounding cryptostorm.

So... blah. It's a challenging situation.

In business terms, we'd be far better off pushing out the Dolphin widget without tokens2 or voodoo - heck, in business terms both are probably not worth doing (in conventional business terms, anyhow)... at least, not in the short term. We'd be better off just spouting random stuff about security-this and fastest-that and strongest-everything and whatever - and smiling all the way to the bank. But... we've this thing, as a team and as a project, about leading with our actions and not just with empty words (and yes, I have a surfeit of words, as always ...but I like to at least tell myself that even my textbticks mostly relate to actions we've done or are doing, and not just to hot-air "wouldn't it be cool if" hypothesizing). That means we don't do so much of the heavy hype-cycle of things we've long been doing well. Which means we pretty much suck at (conventional) marketing, admittedly. Nobody's really arguing that point, eh?

Anyhow.

Feedback and creative thinking appreciated, wrt the above. There's no question df has produced already a brilliant piece of software engineering, in the alpha Dolphin widget. And there's no question he can move it to full production with his characteristically understated professionalism, competence, and integrity. That's all taken as a given. What's open is whether we, as a community, lobby him to hold off on code freeze (metaphorically) until voodoo/tokens2 is ready to bake into it... or do we set those aside, get the Dolphin into the seas of beta release, and then loop back to - as a community, and as a team - define how the Dolphin widget evolves forward to embrace voodoo/tokens2.

There's more, but this post is already too long. (mostly the "more" relates to cross-platform widget support... which is a big, important, open-ended subject in its own right)

Thanks, to everyone, for being the heart and soul of cryptostorm. This project has developed and evolved into something bigger than any one person, indeed to something bigger than the founding team ourselves. It's as much community, and the passion of our community, as it is a business - which is beautiful, and scary, and wonderful to see. It's something new under the sun: something good, something important. Thank you for the honour of allowing us on core team to work with such a beautiful thing.

Just for the record, I've been using the alpha v3 widget since about 30 seconds after you initially posted the link, and I've yet to run into any issues with it. It works great, it exits out without crashing (narwhal still crashes for my every time I exit). So in my opinion, this alpha build is even more stable than narwhal. I like it alot.

I just can say WOW for your dedication CS team. Definitely exciting times are coming with widget v3, voodo.network, deepdns and tracker smacker.

I have been testing v3 alpha and it doesn't crash too on Windows 10 x64.

What I did notice is that every time I opened it asked me to update OpenSSL (and libraries) plus OpenVPN. I opened once the cryptostorm widget with admin rights and made the update and is not nagging yet.

1: the list here https://cryptostorm.nu/nodelist.txt is different for one node, there is not voodoo server; i ask this because when i try to update nodes in v3 button stucks, seems like blocked and nothing happened. I need to close widget and open it again;

2: Voodoo Isle of Man:IMN is not accessible from windows? What mean IMN? I would like to access to this "Isle of Man", seems "cool".

I LOVE THE STORM STUFF

1: solved, when i have INSTALLED this software http://iphiderpro.com/index.html the Update Button stucks, no updating works and the only way is Exit. I have done all possible tries and confs but the only solution has been to unistall iph completely. Obviously it's a pa****ed version but there is not difference with "standard" and so on. It was confy sometimes for all those ip btw i will use it in vm only.

Why when i "open" cs3 i have no popus about updating ssl stuff?

2: i have an aleaph token but still i have not activated it, i am using still my monthly token and i will buy an other one to support more. So question in pont 2 remain.

A new one: i will can replace my "old/new" aleph token with new version 2 soon when this new will be ready?

The V3 widget is working pretty well on my Windows 7x system, better than the v2.22 release. In-line updates are working smoothly, only issue is that the signature check for the widget software update appears to be failing, but the openvpn and openssl component updates work without any apparent errors. I'll try to get a screenshot of the signature/checksum error if it happens again.

Outside of that, the only other issue I'm running into is that when I set Cryptostorm to launch at login and connect automatically, there is nothing visible on the desktop, taskbar, or notification area. Process explorer shows that Cryptostorm is running and connected however, and visiting an IP check web site confirms that traffic is routing over the Cryptostorm network. If I want to disconnect Cryptostorm, I have to kill the process tree using Process Explorer.

sysfu: that's one of the reasons v3 should be considered pre-alpha, it's not finished yet. That message is referring to the dnscrypt-resolvers.csv file, which is updated when you connect, but not all servers have been configured yet for the internal server that will have those files.

df wrote:Just to ensure everyone that I (df) didn't fall off the face of the earth, I wanted to give everyone an update on what's coming in v3 of the widget. I wanted to be done with this version on the 1st of 2016, but I kept adding features and fixing new & old bugs etc. that I had to push the release date further.

The current functional features are:DNSCrypt support!
Now your DNS queries will be hidden from your ISP before you even connect to CS, so unless they're keeping track of all of our DNSCrypt/DeepDNS IPs (which is why you can choose a non-CS DNSCrypt server in v3), they won't even know you're connecting to CS.

Another feature is updates via the VPN:
Before, updates were accomplished simply by grabbing https://cryptostorm.nu/latest.txt and checking if the version listed in that file after "LATEST:" is greater than the version you're using. If latest.txt says you're using an old version, a lazy `start https://cryptostorm.nu/setup.exe` was executed, which means your default browser would goto https://cryptostorm.nu/setup.exe. This method sucks for one main reason: If you can't reach cryptostorm.nu, you can't get updates. So if your ISP is blocking requests to cryptostorm.nu, or cryptostorm.nu goes down for some reason, no updates for you.

For v3, I've decided the best alternative method to this is implementing a server-side dummy interface that has a webserver listening on http://10.31.33.7/ that can only be accessed if you're connected to the VPN. On that webserver is the same latest.txt. That means that if you can get on the VPN, you'll be able to get that latest.txt file using the VPN's tunnel instead of relying on plain HTTPs (unless Apache dies on that particular server, which is highly unlikely thanks to a minimal setup + deamontools).

Adding onto the above feature is automatic updates of the OpenSSL and OpenVPN files that power the widget. It's still being tested, but the idea is that when, after connected to CS, the widget downloads http://10.31.33.7/latest.txt, it not only includes the latest widget version, but also the latest OpenSSL and OpenVPN (and their library/.dll) versions, then downloads their updates if they're newer than the versions the widget is currently using. The most obvious problem I could see with this idea is that if someone somehow managed to hack into a node and uploads malicious OpenSSL/OpenVPN binaries to this http://10.31.33.7/ webserver, they could gain access to the client's system. So to prevent that, asymmetrical cryptography is used. The widget downloads the updated file to a temp directory, then it downloads that file's sha512 signature. Included with the v3 widget is the public key that will be used to verify the downloaded files signature (along with ossl.exe, a win32 precompiled openssl.exe), as seen in this code:

Since the private key used to sign these binaries are only on my personal system, hacking into the node won't give you the ability to modify these files without the v3 widget bitching and whining about it.

I'm thinking this would also be a good method for updating the widget without requiring the user to reinstall via the setup.exe each time too (i.e., the widget just automagically downloads [and verifies] client.exe for the future versions).

The other major feature is also a bugfix. If the widget is left running forever, eventually the system may enter a suspend/hibernate state. Now there's code that'll detect such an event, and disconnect the widget since all other internet related features of Windows will be disabled during this period anyways, then the widget will reconnect when the system wakes up. The problem before was that when you resume from suspend/hibernate, the widget would complain that it couldn't resolve anything, because the v2.22 widget told the OS to use the DeepDNS IPs for DNS, but on un-suspend/hibernate, those IPs are no longer accessible. So with v3, it'll detect that power state and adjust accordingly.

The rest are mainly minor bugfixes:

If you click the systray icon and the widget main window is already opened, but minimized or not in focus, nothing happens. Now it'll restore focus to the widget.

This one's a bug I'm considering a feature: user connects like normal, goes to options, changes DNSCrypt server, goes back, now they're using 127.0.0.1 (DNSCrypt) instead of the pushed DeepDNS server.
Wireshark says even by doing that the DNS still goes thru the VPN. So I'm not fixing this mistake

Fixed an old bug where if the node list can't be grabbed from https://cryptostorm.nu/nodelist.txt, the drop down node list in the widget would be emptied out (I just needed to undefine a buffer before a certain function).

Fixed an odd window render bug where the if the splash screen is disabled the default Tcl test window would show up before the main widget screen for about a half a second. Not really that important, but looks sloppy. Fixed now.

Fixed that occasional bug where some users get an Options window that's a square (which hides buttons etc.) instead of the intended rectangle.

Fixed the bug where if the widget can't update the node list, any further attempts to try to do so would fail (a buffer needed to be cleared).

Even more minor GUI updates include: Changing the text on the main window to code that mimics a hyperlink, so you can click on those text links. Also, since Tk's GIF capabilities are dumb/non-functional, I created some code that'll sorta mimic the visual aspects of a GIF so the world icon looks more animated

ANYWHO
I'm still working on the "update while on CS" code, and I'm debating on whether or not to push the release of v3 even further just so obfsproxy support is included. I dunno yet, if that ends up not taking alot of time to implement, I'll do that. If I find a bunch of problems in implementing obfsproxy, I'll save that for v3.1

I consider this effort "a big deal". Primarily because it relieves those like myself who might unwittingly screw up Cryptostorm's installation.

But at least here, we've seen recent failures with other security efforts and are hoping that Cryptostorm will solve these problems for us High on my list is the need to purchase and configure two ipods with "Signal" from Open Whisper Systems, perhaps Tox if it is past beta.

Well, we've never owned Apple products before! And I'm really, really worried configuring openvpn on the ipod will be a disaster.

Also have some Ubuntu machines here which really need configuration up to the quality of your widget 3.0 effort.

Any hope for such fixes?

Believe Apple's products are really BSD? So installation of pfsense might be possible? Still feel that exclusive connection to internet via Cryptostorm into a special "Signal" portal would be more efficient. We don't plan on using these things for anything except voice (text?). All other functions are just hazards.

I tried to avoid anything resembling smartphones by going with those Jack Pairs - but it now looks very much like they'll stay vapor

ALRIGHTY! I think I've finally gotten v3 to a point that I can consider it a proper beta.
That means I now need people to test it out and tell me all the horrible ways it breaks your system

Most of the features in it were listed above in the original post (DNSCrypt, in-tunnel updates, yadayada).
One feature that I said I would implement only if it didn't end up taking too long to implement ended up taking a long time to implement :/
BUT, it seems functional finally: obfsproxy! (using the obfs3 transport). So if someone with access to any machines in China or Iran or similar places could test out the widget, that would be helpful. There's only one obfsproxy enabled server at the moment (it's at the bottom of the node list in the v3 widget), but if it ends up being popular enough we'll add more servers.

P.S. In all my tests, it appears that installing v3 when you've already got v2.22 will NOT remove your saved token, so it should be fine installing v3 to replace v2.22. For anyone that had the pre-alpha v3 widget, this v3 should be able to replace those outdated files without breaking everything

Warning: Setting the [Setup] section "OutputBaseFileName" to "setup" is not recommended, all executables named "setup.exe" are shimmed by Windows application compatibility to load additional DLLs, such as version.dll. These DLLs are loaded unsafely by Windows and can be hijacked. Use a different name, for example "mysetup".

Tested on a near pristine Win7 SP1 32 machine used *only* as a proxy gateway. Unit is equipped with RollbackRX - so it's essentially a virtual machine. Have been using this for almost two years with Cryptostorm without major issues. Our connection is fiber.

Could not connect through any Voodoo labeled connection, it just cycles endlessly.

Obfsproxy site yields very weird results finally locking up their test. I also had to kill the client once using processexplorer. The standard VPN connections don't seem to connect as well as they did with "Narwhale".

Sorry to be the bearer of bad news. If you can tell me how to collect the logs, I'll try to gather them for you.

Will play with this some more, but if it keeps performing like this I'll reboot back into Narwhale.

Using the latest (cryptostorm_setup.exe, that matches df's posted hashes above) v3 widget and it's a smoother and quicker overall experience. Which is super-sweet

Now if we could somehow get it fully ported for Mac OSX, Linux, or Android/iOS, your path to world domination will be set!

---------------------------------------------------------------------------------------------------You derive personal satisfaction from the continued existence of the near perfect day-night cycles of the hyper cube.....

&#9658; Show Spoiler

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

Of note, while help bring this out of alpha (in IRC), I tested the sleep/hibernate functionality, and it works. For those of you that use it on laptops often

---------------------------------------------------------------------------------------------------You derive personal satisfaction from the continued existence of the near perfect day-night cycles of the hyper cube.....

&#9658; Show Spoiler

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

@wwee
That's incorrect. The type of DNS leak protection they're talking about only applies AFTER you connect to the VPN server. DNS hijacking and all the other DNS security issues still apply to pre-connect DNS queries, which is where DNSCrypt comes in.

@Guest
Yes, you can use obfsproxy on linux. The only server with it enabled at the moment is obfs-windows-ussouth.cstorm.pw on TCP port 443 (can't use UDP + obfsproxy, afaik). The widget starts obfsproxy locally using the command:

df, wanted to report a weird crash the other night. CS was running and connected, I left it alone for a bit, I don't think I was doing any torrenting, just connected to IRC and AIM, and auto-refresh for Gmail and the like.

Anyway, I came back, and refreshed some things, they took a really long time to error out, but the error was a "You're not connected to a network" rather than a 404 or anything.

So I popped up CS, which said it was connected, but freaked out and shrunk a tiny bit (like it was closing, but frozen), and took a few minutes doing nothing, not even the 'sort-of-whiteout' that happens in Windows 8.1 when a program freezes.

Anyway, killed the client and associated processes (Process Explorer, FTW), and waited a bit for all connections to resume.

Not sure if there are any logs in the client install directory, or if there's a way to turn it on, should it happen again, but there it is!

---------------------------------------------------------------------------------------------------You derive personal satisfaction from the continued existence of the near perfect day-night cycles of the hyper cube.....

&#9658; Show Spoiler

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

and as I've stated before, this v3 widget should not be used by anyone because it's not finished yet.
The VPN bits are probably stable enough to keep you secure/anonymous, but if you require more security/anonymity, wait for the official release.

and don't bother filing/posting any bug reports, all the stuff mentioned so far I already know about and am working to fix, or already have fixed.

bug reports will be welcomed when I release the official alpha. I'll probably call it a beta just to avoid confusion from the other posts here, or I'll call it a gamma just to screw with everyone

V3 has been running without failure since my last post - albeit with the normal VPN nodes.

What can be done to get the voodoo and obfsproxy functions working?

Another supreme irony for you? Our primary machines are all Ubuntu - yet we access the internet through a Win 7 pro guest account proxy (rolling eyes). So even though this place has moved on - we're *still* using your Windows effort near exclusively.

It's hard for users of "other" OS products to "go with the flow" - but I bet we're not alone either.

Thanks I'll give it a try and do some testing. Productive use will wait until it's available in Europe though.

It's a shame that obfsproxy only works with TCP. I didn't know that. This will cause some performance hits for sure... :\ But it's better to have slightly worse performance compared to having your VPN blocked altogether.

---------------------------------------------------------------------------------------------------You derive personal satisfaction from the continued existence of the near perfect day-night cycles of the hyper cube.....

&#9658; Show Spoiler

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

@JTD121
That error was from the pre-alpha v3 (the installer was named "setup.exe").
It should be fixed in the current one (installer named "cryptostorm_setup.exe").

It's possible that installing the current v3 didn't correctly overwrite the existing pre-alpha v3, or at least some of it's files.
So if you continue to get that error with the latest widget, save off your token somewhere then uninstall the widget completely and make sure there's no remaining files in C:\Program Files (x86)\Cryptostorm Client\ , then reinstall.

Okay, no problem, I suspected something along those lines. Will do that at some point in the near-future. Is there any updated build at this time, before I go through that (relatively painless) procedure?

I have no problem wiping away my token saved in the widget, I have it saved elsewhere ready to be copied, if need be!

EDIT: Uninstalled and reinstalled, after verifying hash posted above (didn't re-download). Also wiped out the CS install folder, just to be safe. Connected all up again, will report back with any issues!

---------------------------------------------------------------------------------------------------You derive personal satisfaction from the continued existence of the near perfect day-night cycles of the hyper cube.....

&#9658; Show Spoiler

Hidden Content

This board requires you to be registered and logged-in to view hidden content.

If the hashes listed above match the one you've got, then it's the latest build.
But like I said, it's possible that some stuff left over from a pre-alpha install is conflicting with the latest build.

This is why I was upset when PJ leaked the b.unni.es URL containing the pre-alpha v3.
I never intended to release any sort of pre-alpha (a.k.a. "Not yet finished") version, so some of the code in it was there only for my own debugging purposes, and it was going to be removed before it reached beta.
Because of that, there might be conflicts between pre-alpha and the current beta.

Thanks to @microsol (on IRC here) for pointing out a bug in the openvpn/openssl version checking code.
Turns out the code that did those checks were in a section of code that only runs if the splash screen is enabled.
So disabling the splash screen would cause the message:

"You are using OpenVPN version *blank* and the latest is 2.3.11.
Would you like to upgrade?"

To appear after every connect, even though you're already using the latest openvpn/openssl.

using win xp sp3
currently using sexynarwhal2_22 - no major issues apart from occasional crashing while running with standard node (but rare).

installed beta version of 24 may 2016
(after having uninstalled sexynarwhal2_22 and deleting cs and tap-windows folders in program files and rebooting)
on installing getting error installing tap-windows, but installation complete.
on running the widget v3, getting it's getting longer than 60 seconds, trying again, at the 3rd automatic try getting this message:

df wrote:ALRIGHTY! I think I've finally gotten v3 to a point that I can consider it a proper beta.
That means I now need people to test it out and tell me all the horrible ways it breaks your system

Most of the features in it were listed above in the original post (DNSCrypt, in-tunnel updates, yadayada).
One feature that I said I would implement only if it didn't end up taking too long to implement ended up taking a long time to implement :/
BUT, it seems functional finally: obfsproxy! (using the obfs3 transport). So if someone with access to any machines in China or Iran or similar places could test out the widget, that would be helpful. There's only one obfsproxy enabled server at the moment (it's at the bottom of the node list in the v3 widget), but if it ends up being popular enough we'll add more servers.

P.S. In all my tests, it appears that installing v3 when you've already got v2.22 will NOT remove your saved token, so it should be fine installing v3 to replace v2.22. For anyone that had the pre-alpha v3 widget, this v3 should be able to replace those outdated files without breaking everything

Warning: Setting the [Setup] section "OutputBaseFileName" to "setup" is not recommended, all executables named "setup.exe" are shimmed by Windows application compatibility to load additional DLLs, such as version.dll. These DLLs are loaded unsafely by Windows and can be hijacked. Use a different name, for example "mysetup".

Obfs proxy now working without issues, was finally able to connect to a Voodoo exit too. Is it possible my earlier difficulties were just related to node capacity?

just so you know the latest alpha crash after launch on Win 10.
Un-installed previous version and even opened up a new user account to make sure
install would not be messed up by something else. I can see the splashscreen and then very
quickly the CS widget window crashing and closing.

I'm not sure how to help debug out this crash on win10 but I can try to help if needed.

df wrote:Just to ensure everyone that I (df) didn't fall off the face of the earth, I wanted to give everyone an update on what's coming in v3 of the widget. I wanted to be done with this version on the 1st of 2016, but I kept adding features and fixing new & old bugs etc. that I had to push the release date further.

The current functional features are:DNSCrypt support!
Now your DNS queries will be hidden from your ISP before you even connect to CS, so unless they're keeping track of all of our DNSCrypt/DeepDNS IPs (which is why you can choose a non-CS DNSCrypt server in v3), they won't even know you're connecting to CS.

Another feature is updates via the VPN:
Before, updates were accomplished simply by grabbing https://cryptostorm.nu/latest.txt and checking if the version listed in that file after "LATEST:" is greater than the version you're using. If latest.txt says you're using an old version, a lazy `start https://cryptostorm.nu/setup.exe` was executed, which means your default browser would goto https://cryptostorm.nu/setup.exe. This method sucks for one main reason: If you can't reach cryptostorm.nu, you can't get updates. So if your ISP is blocking requests to cryptostorm.nu, or cryptostorm.nu goes down for some reason, no updates for you.

For v3, I've decided the best alternative method to this is implementing a server-side dummy interface that has a webserver listening on http://10.31.33.7/ that can only be accessed if you're connected to the VPN. On that webserver is the same latest.txt. That means that if you can get on the VPN, you'll be able to get that latest.txt file using the VPN's tunnel instead of relying on plain HTTPs (unless Apache dies on that particular server, which is highly unlikely thanks to a minimal setup + deamontools).

Adding onto the above feature is automatic updates of the OpenSSL and OpenVPN files that power the widget. It's still being tested, but the idea is that when, after connected to CS, the widget downloads http://10.31.33.7/latest.txt, it not only includes the latest widget version, but also the latest OpenSSL and OpenVPN (and their library/.dll) versions, then downloads their updates if they're newer than the versions the widget is currently using. The most obvious problem I could see with this idea is that if someone somehow managed to hack into a node and uploads malicious OpenSSL/OpenVPN binaries to this http://10.31.33.7/ webserver, they could gain access to the client's system. So to prevent that, asymmetrical cryptography is used. The widget downloads the updated file to a temp directory, then it downloads that file's sha512 signature. Included with the v3 widget is the public key that will be used to verify the downloaded files signature (along with ossl.exe, a win32 precompiled openssl.exe), as seen in this code:

Since the private key used to sign these binaries are only on my personal system, hacking into the node won't give you the ability to modify these files without the v3 widget bitching and whining about it.

I'm thinking this would also be a good method for updating the widget without requiring the user to reinstall via the setup.exe each time too (i.e., the widget just automagically downloads [and verifies] client.exe for the future versions).

The other major feature is also a bugfix. If the widget is left running forever, eventually the system may enter a suspend/hibernate state. Now there's code that'll detect such an event, and disconnect the widget since all other internet related features of Windows will be disabled during this period anyways, then the widget will reconnect when the system wakes up. The problem before was that when you resume from suspend/hibernate, the widget would complain that it couldn't resolve anything, because the v2.22 widget told the OS to use the DeepDNS IPs for DNS, but on un-suspend/hibernate, those IPs are no longer accessible. So with v3, it'll detect that power state and adjust accordingly.

The rest are mainly minor bugfixes:

If you click the systray icon and the widget main window is already opened, but minimized or not in focus, nothing happens. Now it'll restore focus to the widget.

This one's a bug I'm considering a feature: user connects like normal, goes to options, changes DNSCrypt server, goes back, now they're using 127.0.0.1 (DNSCrypt) instead of the pushed DeepDNS server.
Wireshark says even by doing that the DNS still goes thru the VPN. So I'm not fixing this mistake

Fixed an old bug where if the node list can't be grabbed from https://cryptostorm.nu/nodelist.txt, the drop down node list in the widget would be emptied out (I just needed to undefine a buffer before a certain function).

Fixed an odd window render bug where the if the splash screen is disabled the default Tcl test window would show up before the main widget screen for about a half a second. Not really that important, but looks sloppy. Fixed now.

Fixed that occasional bug where some users get an Options window that's a square (which hides buttons etc.) instead of the intended rectangle.

Fixed the bug where if the widget can't update the node list, any further attempts to try to do so would fail (a buffer needed to be cleared).

Even more minor GUI updates include: Changing the text on the main window to code that mimics a hyperlink, so you can click on those text links. Also, since Tk's GIF capabilities are dumb/non-functional, I created some code that'll sorta mimic the visual aspects of a GIF so the world icon looks more animated

ANYWHO
I'm still working on the "update while on CS" code, and I'm debating on whether or not to push the release of v3 even further just so obfsproxy support is included. I dunno yet, if that ends up not taking alot of time to implement, I'll do that. If I find a bunch of problems in implementing obfsproxy, I'll save that for v3.1

Ouch. Hard to tell if I did it, or V3 just doesn't stop *any* connection if it drops. But that appears to be what just happened.

Needless to say, we really need a "died" connection to either stay that way or reconnect.

I'm also becoming convinced that all vpn connections should be obfs proxied. Why make it easy for the punks?

Know Verizon was using DPI. Still unclear if they were messing with connections. Hard to tell if that will be a problem since Frontier can't find their butt with both hands.

I'm pretty sure my Inno Setup pascal code for the installer was incorrect.
It wasn't actually removing some of the cached files it needed to remove in order to update from a previous v3 install, so some of my fixes weren't getting to systems that already had an older v3 installed.

That code is functioning correctly now, but I haven't updated the cryptostorm_setup.exe file yet with the fix.
Got distracted trying to fix an IPv6 DNS leak where disabling IPv6 doesn't appear to prevent IPv6 DNS from going out if your router is pushing it via DHCP.

Also trying to implement that killswitch that people have been wanting for ages.

EDIT:
Yep, the previous Inno code I was using didn't completely uninstall the previous v3 widget installation.
So for those of you out there that were testing each new v3 build, but not uninstalling the previous v3 build, you might have had older/cached/non-fixed files still on your system.

The current version is still listed as "3.00" in the program, but the actual build version is "3.0.0.44".
You can view the build version of the v3 widget you have installed by going to "C:\Program Files (x86)\Cryptostorm Client\bin" then right-clicking on client.exe then going to "Properties" -> "Details" and look at the "File version" or "Product version".

I think in the next build I will replace that hard-coded "3.00" with whatever the client.exe "File version" is to help avoid confusion.

EDIT: Latest build version is now "3.0.0.46". I just added the above thing where the build version appears in the options window next to the "Widget version" area, so no more having to right click -> Properties to get the build version.
Also added some fixes for the in-tunnel updating code, and upgraded the back-end OpenVPN/OpenSSL.

I just finished compiling build version 3.0.0.48, which includes a dnscrypt-proxy related bugfix, but is also probably unrelated to your issue.

Did you try uninstalling the widget? It might help to verify that the files were really uninstalled by checking the "c:\Program Files (x86)\Cryptostorm Client\" folder after uninstalling. The only folder that should be in there is "user", which contains the file that has the stored token.

I just tested 3.0.0.48 on a physical win10 machine, and a win7 VM, and a win8.1 VM, they all worked fine with it.
The win10 machine has some stuff installed, but the win7 and win8.1 VMs are pretty bare. The only other program installed on the win8.1 VM is Notepad++.

So it's possible that another program you have installed is interfering with client.exe.
Not sure why another program would do that though, client.exe is just a GUI frontend to some console programs.

If you've verified that the uninstall worked and no other programs are interfering (or modifying) any CS files, I could try building a debug version of the v3 widget that includes a console output window that might be able to catch the error that lead to the crash, if it is indeed a problem with the widget code.

Try installing this debug version of the widget - https://b.unni.es/cryptostorm_setup-debug.exe
It's the same as the latest build, but unlike the normal GUI-only program it was compiled to be a console program.
Let me know if the black msdos window that pops up shows any data, or if client.exe crashes before that window even appears.
If so, then there's most likely another program on your system that's either modifying client.exe or interfering in some other way.

EDIT: err, wait a min. forgot to recompile the inno setup script.
try that above link in about 2 mins.

ANOTHER EDIT:
The correct debug version is at the above link now.
The expected output from the black cmd/msdos window will be something like:

That's very odd... I didn't know there was a Windows version > XP that didn't include the "netsh" program...
In my initial tests of the early v3 I was using a win8.1 system, and it had a netsh.exe (in c:\windows\system32\).

If netsh.exe is really missing from your system, then your DNS will end up broken because the v3 widget uses it to determine your current DNS settings and to set your DNS to the dnscrypt-proxy...

Have a look in c:\windows\system32\ (or whatever your %windir% is) and make sure there's a netsh.exe in there.
Pretty sure all win8.1 versions should have one...

Well if you already have a netsh.exe in c:\windows\system32\ then there's probably no reason to download the one I found...

The only reason I can think of for the widget not to be able to find the netsh on your system is if some other program has modified the %PATH% environment variable so that it doesn't include c:\windows\system32\ , which is something no program should be doing.

Open up a cmd.exe and type in:
echo %PATH%
and see if c:\windows\system32\ is in there.

If so, then I have no freakin idea why the widget couldn't see netsh :-D
If not, then something has been messing with your environment variables..