1. 65

  2. 9

    Installation: make

    Delightful! Never heard of Frank Denis before, but he seems like a kind of Batman to the open source community. Shooting fashion photography at day, making crypto software at night.

    1. 2

      He is also on twitter 24/7 sharing great stuff. I have been following him for years.

    2. 10

      Who is this guy? A frickin’ super genius. Look at the other cryptography work they’ve done.

      Some people are on a whole other plane of existence, I swear. What a beast.

      More on topic: I wonder how many people will use this with confidence? Is OpenVPN truly that difficult to setup, that you’d just write your own cryptographic primitives and VPN server and client?…

      1. 14

        Who is this guy?

        Someone who has earned a verbification of his name in the cryptography community, as anointed by Thomas Ptacek.

        (Disclosure: I am lucky enough to work with Frank.)

        1. 2

          Is OpenVPN truly that difficult to setup

          Not IME, though there’s certainly the possibility that the simple path I’ve taken has left holes I’m unaware of. What OpenVPN certainly has in its favour is Android apps, which is a must-have for me.

          1. 3

            It’s definitely difficult to set up an OpenVPN server and understand all the configuration options. Did you set everything you need to, or forget something important? Did you read the logs for warnings about unsafe configurations? Have any defaults been weakened to better support legacy things you don’t use? If you use an OpenVPN provider, did they do all those things?

            Personally, it’s too much stress for me. I use strongSwan because I investigated all those questions at work, that time was paid for. But I wouldn’t have done that on my own time.

          2. 1

            Is OpenVPN truly that difficult to setup

            I’ve never set up OpenVPN so I don’t know by experience, but now that I look up guides or scripts it does seem quite complex. Setting up dsvpn was so simple that it took me ~2 minutes, and I’m now tunneling to my server to post this, It’s pretty cool.

            1. 1

              I wonder how many people will use this with confidence?

              Definitely not me. It’s literally a few days old, which from a purely statistical point of view, it is very likely to have all kinds of problems that weren’t obvious to the author as he was writing the code. Says right there in the readme, “This is a weekend project,” which means there was almost certainly little to no design process, no significant amount of peer review of the design, and obviously no real-world testing. The guy who wrote it can be as brilliant as they come but there is no such thing as writing bug-proof code.

              1. 4

                I highly doubt it’s 100% bug free, but it’s also ~1000 lines of C code. When people talk about auditing open source for bugs and vulnerabilities, I look at things like StrongSwan and I’m skeptical. It would take days just to get comfortable with that code. But I read DSVPN in half an hour. It’s nice, clean, well-designed code.

                I read both source files from top to bottom. The “design process” is simply that the author clearly has a rock solid understanding of VPNs. You have to know exactly what you’re doing to write a fully functional VPN in that little code. And he’s added lots of optimizations that only a seasoned systems engineer would think of off the top of their head for a weekend project. He sets some TCP socketopts to make congestion control and kernel buffering much more responsive than you’d get with a more naive TCP-based VPN.

                I agree DSVPN is extremely new and shouldn’t be used for Serious Security. But it’s small and simple, so I think it will achieve an asymptotically small bug count quickly, and I will soon have more confidence in it than big sprawling projects like OpenVPN and StrongSwan. And for casual coffee shop purposes, for a sufficiently technical user that understands how the firewall and routing setup commands fail, I think it’s already safe to use.

            2. 3

              If http/3 (quic) ends up becoming popular enough, and since it is built atop udp, we may finally be able to leave the world of tcp wrapped vpn’s behind. Hopefully I live long enough to see it!

              1. 4

                Warning! HTTP/3 is HTTP over QUIC, like that :

                IP + TCP + TLS + HTTP
                IP + UDP + QUIC + HTTP

                I don’t like the statefullness of QUIC: it means routers / servers will need memory for holding connection states, just for the sake of resuming a connexion without extra handshake, not good for privacy either, you can now strongly identify (as in cryptographic proof) someone beyond any kind of NAT (if end to end encryption is what you want… :)). Even a VPN over tor won’t cut it (you won’t get the real IP though).

                But I like the approach of QUIC: how often do we debug TLS with netcat? That is where the TCP part would be useful to. So let’s squash theses layers into a performant and hopefully simpler one.

                This is also the approach of MinimaLT and CurveCP, and maybe more…

                1. 3

                  servers will need memory for holding connection states

                  But TLS has had resumption tickets for ages too, on top of non-cryptographic connection state in TCP…

                  1. 2

                    As far as I know, TLS session tickets are held by the client, not the server. Many HTTPS servers use a small session cache to share TLS parameters between threads, but that’s just for active connections. I think @josuah is talking about the QUIC-level logical connection, a separate concept that lives in userspace. The QUIC state for each connection ID spans multiple kernel-level connections, allowing the client to seamlessly interact with the server even as it changes IP addresses and networks.

                    1. 1


                      And given that is UDP, there is not even the notion of “Connection” that is more specific to TCP.

                      Maybe the point was to squeeze the last bits of performances so that they do not regret it further on…

                      And maybe it is entire possible to make compatible client and server that do not preserve the state for longer than one QUIC-level connexion.

                      Now, all we need is a nq as opposed to nc and some proxies to mirror the traffic from TCP (in the datacenter / back-end) to QUIC (for between the end client and reverse proxy).

                    2. 2

                      Eliminate the State! :)

                2. 3

                  This is cool. I like the fact that it’s designed to work on terrible WiFi networks.

                  My main need in a VPN is an Android app, though. I’ve recently switched from OpenVPN to WireGuard, mainly just because I can now. But it’s true neither of those will work on a really terrible public WiFi that you need to tunnel out of. I’ve generally used Tor for that, but admittedly the performance is terrible.

                  The WireGuard Android app is pretty bare-bones. If I had a few more spoons, I’d use its source as a guide to writing an android app for dsvpn.

                  1. 1

                    I use openvpn and sslh on the server to get out of terrible wifis. That has been working quite well so far.

                    1. 1

                      Yeah, that looks like it’s the way forward, at least for now.

                  2. 3

                    Any feature request mentioning systemd. Sad to still see a lot of hatred against systemd (for no good reason in this case).

                    1. 6

                      I think the ‘good reason’ is pretty clear in this case, and not particularly hateful: the author wants to run his software on MacOS and OpenBSD, neither of which use systemd. If anyone really wants this as a systemd service, just fork it and support it yourself. Seems quite reasonable to me.

                      1. 5

                        I agree with @minimax, the author makes it clear it’s a personal project for personal use. And he even links to contributed systemd unit files in the README. So I think it was less a jab at using systemd, and more a preemptive refusal to integrate with systemd APIs directly in the VPN code. There has been controversy about systemd wanting unrelated software to integrate before, and I fully understand the author not wanting to start down that road.

                        1. 2

                          Note that this is not attacking systemd directly but practices from the systemd community behavior.

                          Besides, the approach of systemd is to ignore some of the existing conventions to propose improved ones.

                          Due to Debian choices, every single daemon software on the planet gets confronted to this choice of integrating systemd specifics or not.

                          He states its decision early, but the question was probably going to come anyway, because a Fe/deb/arch user may encounter something to be improved regarding systemd integration.

                        2. 2

                          Gotta wonder how he avoids linking an SSL library. I suppose charm is used elsewhere for crypto primitives? Or is this SSL from scratch?

                          1. 2

                            It’s not SSL at all. It just uses port 443 by default, because that’s not usually firewalled.

                            1. 2

                              So just encrypted stuff over a socket?

                              1. 2

                                Yep. “Dead simple.”

                          2. 1

                            “OpenVPN is horribly difficult to set up.”

                            Not at all, at least on Debian.