Hacker News new | past | comments | ask | show | jobs | submit login
SigmaVPN: Stateless OpenVPN Replacement Using NaCl Encryption Library (frozenriver.net)
128 points by zx2c4 on Apr 16, 2014 | hide | past | web | favorite | 66 comments

This code is as simple as the project owners say it is, but a couple things about it that I wish were different:

* The "nacltai" protocol driver uses C VLAs to store attacker-controlled numbers of bytes; a VLA is morally the same as an "alloca" call. I have no clue if this is exploitable but reading it gives me a painful burning itching sensation.

* I sort of wish the authors didn't parse strings to recover crypto parameters from the packets, but instead just used a straightforward binary encoding that would require less use of C's terrible string functions.

I'm still a lot more comfortable with this codebase than with OpenVPN. :)

Have you expounded on your feelings about OpenVPN anywhere? It's my go-to vpn solution so I would love to hear about what I should be using instead (I don't think this is an option since it's only for connecting 2 computers (afaict)).

I'm not sure where grandparent's OpenVPN concern is coming from; OpenVPN has had good security track record:


The source for concern may have started here:


ssh depending on what you're doing https://www.michaelwlucas.com/nonfiction/ssh-mastery

Curious; VLAs are also one of my main pet peeves with NaCl's bundled C++ wrapper. You can't convincingly argue that it's to prevent memory allocations, since everything is passed and returned as std::string. Additionally, VLAs are not even in the C++ standard.

They should be, soon, though. Which is great. I think the last proposal was for dynarray. See here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n264...

Some compilers already support the spec, even if it isn't going to be in C++14.

I still haven't heard a good argument for VLAs. Allocation time? Use alloca!

alloca is even worse, it's non-standard and you can blow the stack just the same.

Syntactic sugar is worth it in many cases...

I agree about strings - you are polite though. It's rank amateur bs.

VLAs too here - but there are many situations where it is necessary to dynamically allocate based on message contents ... just not at this level. alloca is no more a risk than most other allocation methods when it is necessary - at least in the worst case

A VLA is basically just alloca; you can't pass attacker-controlled lengths to it.

(I have no idea if it's an issue here and sort of doubt it, and would not call this "rank amateur bs").

Might that be because OpenVPN uses OpenSSL?

Or maybe because OpenVPN is less auditable relative to something like SigmaVPN?

I'm glad someone is coming at this problem from a different angle.

Maybe the subtext to this submission is "OpenSSL totally sucks so bad you need to evacuate NOW NOW NOW!!!!" If so, I'd point out that now is the time to upgrade OpenSSL, ditch all of your old keys, and keep an eye on the future.

Today is not the day to forklift in a whole new chunk of infrastructure.

Instead, set up a lab, play with it, get a feeling for it.

Maybe someone can help me, it is said It has a time-based nonce, which provides built-in resistance against replay attacks, I'm looking where in the code the time-based nonce is verified/handled on the receiver, but I can't find it.

What I see: when a packet is decrypted the time-based nonce is unpacked here [1] and this function seems to be called from here [2] but nowhere I can't find where this nonce is verified not to be too old, what am I missing?

[1] https://github.com/neilalexander/sigmavpn/blob/c7f60ecfdb22b...

[2] https://github.com/neilalexander/sigmavpn/blob/c7f60ecfdb22b...

This is a real bug. You can see that in the code[0] this was based on that they do at least check the nonce/timestamp.

[0] https://github.com/UCIS/QuickTun/blob/master/src/proto.naclt...

You are correct about this, and I have updated the code to include the replay protection. (Apparently I became sidetracked before!) I am not sure if the method that is used in the quicktun source to prevent replay is ideal, and I am fairly certain that I need to revise the method used to generate the nonce too.


It's encouraged with NaCl to cache the results of the Diffie-Hellman operation. Thus the protocol can be conceptually stateless, but the cache solves the problem of having to do per-packet, public-key operations.

From a quick skim of the code, it does appear that they might be doing this. They are calling the right functions for it (crypto_box_curve25519xsalsa20poly1305_afternm. (See "C precomputation interface" in http://nacl.cr.yp.to/box.html)


I've not looked at the actual protocol, but it's not impossible.

If we assume every packet contains the client's (random, generated at process start) public key then the server could (in theory) perform key-agreement for every packet, decrypt it and handle it. In practice, it would cache the result so that it only does one key-agreement operation per client.

If the server crashes (did you have the server in mind when you said "other side"?) then it looses its cache, but the first packet that the new instance of the server sees will have the client's public key in it so it just refills its cache immediately.

One of the goals behind the primitives NaCl selected was per-packet public key crypto.

As DJB noted in the very presentation he introduced NaCl, public key crypto for all data is in fact very feasible on todays hardware.

FWIW, we built an incredibly easy single click OpenVPN setup tool for DigitalOcean and Rackspace during Sochi: http://www.tinfoilsecurity.com/vpn Enter API key creds, it makes the box for you, sets it up, and hands you a config you can use for your client of choice. (The script is open source for those of you that don't want to enter creds - we don't store them, and actually remove access whenever we can; for example, we delete our own SSH key from DO because they let us).

It's still OpenVPN but might be useful to those that care about this story too.

This is such a nice product, I'm thinking you should be charging for it! I can't quite so who the market would be though. I guess there's not an easy way to target it to the enterprise market.

I've been thinking of how to market this but the only step missing is setting up the client. Bear in mind that this should be fool proof (typed up the instructions for a friend and still ended up with 8-10 steps). Tunnelblick for OSX is straightforward to setup with the provided .ovpn file but takes too many steps.

Thanks for the kind words - our main business is website security testing (check out our homepage at https://www.tinfoilsecurity.com) and we built this mostly for our customers to use to keep themselves safe. :)

There's another tunnel implementation that's based on NaCl called fastd. It seems to be production ready, however some thousands of Freifunk participants use it to connect their Access Points.


This looks promising, but I don't feel good about the fact their SSL cert isn't valid. :/

It's from CA Cert, which isn't trusted in most browsers but I'd consider it valid for this case.

Fair enough.

Their SSL cert isn't invalid, it's from CAcert (http://www.cacert.org/).

This is stateless, nearly zero-configuration, and P2P, among other things. It also uses the same cryptographic primitives and composition as NaCl (purely coincidentally). It supports Mac, Windows, and Linux, and has a GUI control panel for Mac and Windows. There's a clean installer with baked-in auto-update functionality.


/full disclosure: I wrote this.

Could you add some example networks on your frontpage? Preferably with nice network diagrams. It could help sell your product if people know what kind of business cases it helps for (my business is looking for a good solution).

Also, please use something like twitter's bootstrap and buy a nice theme, your site and logo currently look like very untrustworthy. I couldn't get my boss to sign off buying something from a website that looks like that.

I completely agree on the design. I'm working on a big web design rev right now that looks much better.

I'm not sure what you mean by diagrams though. This doesn't work that way. It creates virtual networks that look completely flat, as if you and every other peer were plugged into the same Ethernet switch.

One of my difficulties has been getting this across... you don't have to think about topology. It's easier than that. It's a virtual switch. Install, join network, done. Everything is automatic.

You can peek at the new design here (but don't try to use it): https://test.zerotier.com/

That design is a lot better. But I'd still recommend you look a little more at some professional themes. Also the logo could use some typographic love :)

But a network in which every peer is connected to the same ethernet switch isn't flat, it's a star. But a star network doesn't scale as well as you claim.

Behind the scenes to make it scalable perhaps you build p2p connections, this would make the diagram be more like a complete graph, which it has its own scaling problems.

To solve it, perhaps you have stateless or on-demand connections, so the actual number of connections is lower than the worst case. Or perhaps you promote peers to super-peers and build a stars of stars network.

A couple of simple diagrams answer these questions and quickly let me decide whether your solution is suitable.

It's all three of the things you mention: peer to peer, stateless, and on-demand. It also uses UDP, so it's not opening huge numbers of TCP connections. The only time it uses TCP is if you can't use UDP -- as a fallback mode.

I'm not sure why that wouldn't scale. Even if you had millions of users on a network you'd only be connecting to those with whom you're communicating.

It is also as you mention a star of stars network. The supernodes are at very high bandwidth sites and their number and size can be increased on short order. They only relay data if P2P/NAT-t fails, which only happens for about 1-2% of users. Otherwise they just shepherd NAT-t. They're geographically distributed for high performance: Singapore, Tokyo, San Francisco, New York, Amsterdam, and (soon) Sydney. If a supernode fails it takes 10-30 seconds to fail over.

I have plans to further decentralize and add automatic promotion of nodes at some point in the future, but that's a hard problem that requires more study.

Edit: this isn't just another VPN. This is the result of over four years of work, including a huge amount of research into networks and cryptography. It's a completely new system.

"It doesn't scale!"

Who said it needed to scale?

How many Facebook friends does the average user have?

Do these these networks need to be larger than that?

If users want larger networks they can bridge their VLAN's.

"I don't like your logo!"

I'm using a text-only browser so I really don't care what your logo looks like.

Keep up the good work and ignore the critics.

Suggestion: Make the crypto fungible, so if a user wants to use a different library, e.g., NaCl, they can.


Actually, thank you to the previous poster. I didn't mind the criticism. His point -- "your existing site doesn't look good enough to convince my boss" -- is very valid. The new site looks a lot better and it's not done yet.

It does in fact scale pretty darn well, mostly due to the fact that it's connectionless, stateless, and opportunistic. If you're on a network with ten million people but are only talking to ten, you'll only be sending packets to/from ten.

The supernodes have to know about all ten million, but last I checked that wasn't very much memory... maybe a few gigs tops? So that's what, $20-$30/month per node? Or I could add the ability to put a real database under it and use SSD cloud nodes and handle billions of users with sub-10-ms lookup latency.

Of course if I get that many users that'll all be in the good problem to have category and I'll have plenty of money to scale out and if necessary improve the protocol/architecture. There are many directions I could explore: M:N supernodes with load balancing, various other sharding techniques, moving to beefier cloud providers, further decentralization in the protocol, all of the above, etc. I could set up big labs, run simulations, do all sorts of cool stuff. I've done enough so far to convince me that the problem of monstrously scaling this thing is very solvable. Just have to do the work.

I'm not making the crypto fungible. The protocol does have flags that could be used to indicate new algorithms if upgrading the crypto becomes necessary, but I have been an absolute simplicity nazi with this thing so far and will continue to be.

Interesting projects. What role does the website/service play wrt to the clients? Is it possible to run fully separate networks with just the client?

Any thoughts of how it compares with i2p? (http://geti2p.net/en/)

You could technically set up your own completely separate network -- everything you need is there. You'd just have to fork it. It'd be kind of like forking Bitcoin to make Dogecoin or JuggaloCoin or whatever. But in this case I wouldn't see the point. You wouldn't be able to join networks on the "real" network, etc.

Compared to I2P and Tor: it's neither of those. This is about network virtualization and making it easy to set up ad-hoc networks across physical boundaries. It's not a privacy tool per se, though it is end-to-end encrypted so the content of your data is hidden. My goal isn't to duplicate the work of Tor or I2P-- if you want strong anonymity, use those. (You could use ZeroTier One through Tor, though it would be slow.)

There is an incomplete beginning to a technical FAQ here that answers some of these questions in more detail:


the source code is about two years old. does that mean that the code is so stable that there is no need for patches/improvements? or has the project been discontinued?

Quicktun is still maintained: https://github.com/UCIS/QuickTun

Quicktun used to use C's rand() to generate keypairs (see keypair.c). They still include a blurb about /dev/urandom being insecure and apparently requiring the user to manually input random data. The nacl0 protocol is inherently insecure (null nonce, vulnerable to replay), not sure why they even include that. IIRC, you also pass the private key via environment variable. Lots of horrible flaws for such a small code base.

I'm very impressed with how short and clean the code. I did a very quick code review, and things appear to be implemented sanely (eg, they drop permissions and chroot properly). There aren't many comments, but most of the code is readable enough without it. I don't care much for their coding style (little whitespace, long lines) but that's just aesthetics.

More importantly, QuickTun might have some usability issues. Port numbers are hard-coded, and most configuration options seem to be set as environment variables. This should be expected though, as a result of trying to keep the code as small as possible.

I'd recommend it, but only to someone who's willing to read the source to figure out what's going on. If someone wanted to write their own VPN, it would be an excellent reference. It's definitely not for everyone.

So is SigmaVPN a wrapper to QuickTun or what is the relation here? What do I miss if I use plain quicktun instead of sigmavpn?

Also, does not support Windows

yeah, I am surprised by that, too. Haven't heard about this one until now... and I have had my fair share with various VPN implementations, from OpenVPN to Strongswan.

I'm still searching for something a la tinc, but with a decent crypto story (tinc goes out of its way to say that it probably isn't safe).

SigmaVPN would look awesome, but lacks Windows support. I'd give ZeroTierOne a shot, but that lacks Android support. Any other solutions for a "VPN Of Things" if you will?

What's the recommended non-serious-personal-use VPN these days?

PPTP is completely broken (MS-CHAPv2 especially), OpenVPN is hard to setup and maintain.

I've been using ssh as an impromptu VPN-like thing but I'd really, really like an actual VPN solution.

> OpenVPN is hard to setup and maintain.

That's not true. OpenVPN is the easier, most straight-forward solution when it comes to set-up[1] and configuration (routing, firewalling, client auth, etc.). Try to setup OpenSWAN and you'll see what hard to setup really means. I don't know about new software like SigmaVPN.

[1] Or maybe I am too used to it.

I wrote a ruby script to help with OpenVPN.

https://gist.github.com/arnehormann/9744964 There's a usage howto in the comments and this should be short enough to fully grasp what it does. No third party requirements, just ruby core + openssl.

It creates client and server configuration and creates and manages CA and CRL.

The VPN uses tun mode over UDP. Required changes on the server are written down in comments at the beginning of the server configuration.

If there is sufficient interest, I can make it a real repo so it can get issues and pull requests.

I use n2n for things that don't really matter, it's quite nice and simple, but has some pretty glaring potential if not real security flaws in its design (and the v2 that was supposed to fix some of them seems to be in some kind of deep technical debt hole and tends to crash).

After this thread I'll be looking at fastd and zerotierone, though.

What do you use for things that matter?

Do you have something else to create L2 overlays that is more secure?

Unfortunately, openvpn. :/

As you know, OpenVPN cannot do what n2n can do.

Someone has to run an OpenVPN server. Everyone on the network has to trust that server.

And connections between network participants are not peer to peer.

With OpenVPN and most other VPN's, if I'm not mistaken, each person's traffic passes through a central point: some VPN server/appliance.

This is a major difference and has its own set of security implications.

Has anyone used or know about SoftEther VPN?

I was looking them up the other day they seem very nice.

Link: http://en.wikipedia.org/wiki/SoftEther_VPN

Anybody familiar with this project? Does it successfully and securely achieve what it claims to achieve? What's its status currently?

Link bait title with reference to OpenVPN but not mentioned anywhere on the page.

isnt openvpn stateless if you disable the ping restarts anyway?

LOL for anyone who uses this.

Replacement? Does it talk OpenVPN protocol? No. It is not a replacement.

It's not a clone. It's a replacement. It does the same job, like the car is a replacement for the horse-drawn carriage, but it doesn't run on hay.

It is a VPN software. Calling it OpenVPN replacement is just for getting votes because of current events.

Virtual Private Network isn't restricted to OpenVPN nor has it been at any point...

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact