Hacker News Reader

These days WireGuard is just as easy to set up, and has lots of benefits over sshuttle (it's UDP based, supports roaming a-la Mosh, has a much more solid cryptographic design, and so on).

From the WireGuard installation instructions:

"Generate a private and public key pair for the WireGuard server:"

"umask 077 wg genkey | tee privatekey | wg pubkey > publickey"

"This will save both the private and public keys to your home directory; they can be viewed with cat privatekey and cat publickey respectively."

"Create the file /etc/wireguard/wg0.conf and add the contents indicated below. You’ll need to enter your server’s private key in the PrivateKey field, and its IP addresses in the Address field."

That's not within reach of your average computer user.

> That's not within reach of your average computer user.

Same for sshutle.

I don't think anyone is under the delusion that non-technical users are going to use sshuttle, but not everyone has the will to invest the time and effort doing server side configuration of a VPN client for their personal use. sshuttle makes it simple for anyone who is the least bit familiar with ssh and has some kind of server access or is happy to spin up a VPS quickly, nothing more is necessary.

There are plenty of scripts online that make it incredibly trivial to set up WireGuard (here's mine[1]). This isn't like configuring OpenVPN -- it actually only takes a minute or two to set up.

Given that WireGuard is headed for inclusion into Linux mainline soon, it probably would be a good idea for folks to take a few minutes to learn how to use a technology that is going to be part of core Linux.

[1]: https://github.com/cyphar/dotfiles/blob/master/.local/bin/wg...

Not fair, OpenVPN doesn't take that much more than a "minute or two" to set up and configure. ;) Last time I launched it[1], I could launch and connect to a new OpenVPN instance in less than six minutes, from my iPhone. Desktop is even faster.

[1]: https://github.com/jenh/sevenminutevpn

There are scripts To install OpenVPN in 5 minutes as well so Wireguard has absolutely no advantage there.

Well yes, but OpenVPN has many dozens of different options and my experience with it is that it's a pain in the ass to get the right set of options (on both the client and server) which result in minimal latency and maximum throughput.

But you're quite right that if you already have a config that you know works, WireGuard has no significant advantage in this area (in terms of ease-of-configuration -- though the keys being quite short is nice for SSH-like key distribution). But if you're starting from scratch then you need to first figure out what is the right configuration to use (or you need to pick from the many dozens of "set up OpenVPN quickly" scripts) and then you need to hope that your configuration is not insecure.

WireGuard can be set up and work just as well as any other configuration without a script in a couple of minutes (or less than a minute with a script). The script that was linked in a sister comment to "set up OpenVPN quickly" also sets up Apache for god's sake...

It is just as easy as sshuttle to set up. I never said it was easy for an average computer user. Average computer users will probably buy some service which uses WireGuard under the hood.

> has a much more solid cryptographic design

sshuttle uses ssh, which in turn is not wedded to any one cipher. How does wiregaurd improve on this?

Agile cryptography is bad. Wireguard uses just solid, single, unconfigurable crypto.

Today it's solid. And tomorrow? The story for fixing it if it breaks is a flag day - works fine when you have ten users, not so much when it's ten million.

The "agility is bad" crew have a decade or two to wait before they can show anything at all meaningful beyond "my new thing is newer than your old thing".

That doesn't make them wrong, but it makes their position unproven in practice.

There is plenty of evidence that cipher agility weakens cryptographic protocols.

By having cipher agility, both clients and servers are incentivised to support the widest possible set of ciphers (because nobody can agree on what cipher to use). This means that it's hard for a known-bad cipher to stop being used (see: the entire history of RC4 usage in TLS) and any downgrade attacks become catastrophic (see: the entire history of SSL/TLS). It also ends up adding complexity to the protocol -- which is always a good thing to have in cryptographic protocols (see again: SSL/TLS)!

Most importantly, if all currently-known ciphers are broken tomorrow, then all servers and clients will have to be upgraded in order to be secure. So cipher agility doesn't help you with the doomsday scenario (everyone needs to upgrade anyway) instead it just ensures that older (completely insecure) clients will still be able to communicate with servers. Why is that seen as a feature? If you really want an insecure fallback mechanism you can implement it with non-agile systems by supporting the two most recent versions of the protocol (I expect this is what WireGuard will do once it's upstreamed). But not everyone wants the "feature" that some clients will silently become insecure.

I don't understand what you're saying with this point:

> The "agility is bad" crew have a decade or two to wait before they can show anything at all meaningful beyond "my new thing is newer than your old thing".

How can the "agility is bad crew" prove their point in a few decades if you're arguing that we shouldn't use such protocols? If they followed your advice, there wouldn't be any zero-agility protocols to compare against in a few decades...

Your last point first: Am I arguing that "we shouldn't use such [explicitly never agile] protocols"? I don't see that.

I'm arguing that the case for them is weaker than is often put, but that's not the same as nobody should use them. If a flag day is fine for your use case there's very little reason not to choose this design approach, it is simpler and simpler is good. But you'll notice that the example cited (including by you) for why agility is bad is almost invariably TLS and clearly a flag day isn't practical for TLS because it's far too broadly used.

TLS illustrates my other main thrust of concern on "agility is bad". You describe RC4 as "known bad" and the downgrade attacks as "catastrophic" and this sort of apocalyptic thinking is very popular in the "agility is bad" crowd, but it doesn't truly reflect the ground reality for actual users which is that things went from "It's definitely fine" to "It's probably fine but to be sure we should upgrade". Grey areas are a real thing.

There were protocols that didn't exhibit any cipher agility before by the way. Lots of them. What happened was that they broke, and so agility was added to them retrospectively in new versions that fixed the brokenness. The arguably new thing in the latest round of "no agility" protocols is a supposed determination never to do this. To see how that works out, as I said, you'll have to wait a decade or two.

I'm not talking about the selection of ciphers (though WireGuard doesn't have cipher negotiation because it has shown to be a universally bad idea because of downgrade attacks -- instead it uses versions and requires strict upgrades to operate).

Among many other things, you cannot do a port scan for WireGuard servers. You can do a port scan for SSH. This is because the WireGuard handshake was designed such that there is no response to unauthenticated packets (the first packet is authenticated by the client knowing the server's public key -- something port scanners won't know).

Jason Donenfeld has a few talks[1] that explain why the cryptographic design is the way it is, and it has several very clear improvements over SSH (as a VPN protocol).

[1]: https://youtu.be/CejbCQ5wS7Q

ok, but if using ssh keys anyway there is basically no difference other than using rsa.

There is still a difference. Even if you use SSH for some things (which you could only expose through WireGuard instead of making it internet-accessible), WireGuard protects your VPN traffic in ways that SSH does not. WireGuard renegotiates the session key every 5 minutes (SSHv2 uses one ephemeral key for the entire session), it has identity hiding (you can't tell at any point the public keys of the server or client), it has pre-shared key support to limit post-quantum or ECDH attacks, and so on.

I really can't overstate how awesome WireGuard is. I really would suggest you take a look at it.

But sshuttle is so much simpler if you have ssh access to a remote server. Just a matter of installing it for your os.

https://www.terminalbytes.com/sshuttle-vpn-over-ssh-vpn-alte...

You assume that the user has root access on the remote server, which is not true in many environments (esp. corporate jumpservers).

Okay so this is shockingly impressive.

For those of you who are thinking "eh, I like my `ssh -D8080 user@1.2.3.4` solution", sshuttle has the following two advantages:

1. no need to configure your SOCKS proxy in your applications

2. it works even when dynamic forwarding is disabled on the host you're connecting to

How does this work for walled-garden mobile devices (ie, iOS)?

There's a reason VPN providers have exploded in popularity: mobile internet devices have been mainstream for 5-10 years and they are system-locked but you can install apps.

It doesn't. Instead, you install WireGuard for iOS for free and take a photo of the QR code supplied by your sysadmin, which just encodes a simple text configuration file with an ed25519 key. Then your sysadmin can route all your iOS traffic however they want, whether you are connected to the public internet by cellular or wifi.

BTW how do you make sshuttle autoreconnect?

There is a --daemon option but do not know if it includes this behavior, maybe give it a go. I prefer to keep it in the foreground so I can kill it easily.

If you are using ssh keys you can at least use a bash while loop without incurring any password prompts:

    while ! sshuttle -r user@1.2.3.4 0/0; do sleep; done

_Hold_ ctrl-c to escape the loop

> make any server

Any server you have a login to, right? So in some respects wouldn't a commercial VPN be simpler?

Yes you must have a login... but setting up a VPS is literally a button click these days, it's not going to be much more complicated. no need to even login to an interactive shell to configure anything (or at the most `adduser` if there are no default non roots), all you need is a user name and password, any of the generic VPS images will work no configuration beyond an ssh user.

It's almost as simple, faster, and importantly, far more obscure... vs consumer VPNs which are almost honey pots.

It's also more powerful, you can selectively route things through different servers simultaneously.

This also ties your identity to a provider definitively. That's fine, as long as you tell people that's what is happening. A good consumer VPN that isn't a garbage one offers plausible deniability.

Yes this is true, it really depends what you want from your VPN. For security and anti-cencorship this works, among many other useful things that you can't do with a normal VPN - but if you are evading authorities or something then you cannot be personally associated with the server.

I suppose that negates my point about it's obscurity, since you only care about that if you are evading prying eyes of some sort.

I've updated my original comment to include your point.

If you want to have any hope of anonymity when accessing the internet, use Tor. Don't use a single-hop proxy. Even if you assume that the VPN provider is trustworthy and won't roll over when they're handed an NSL (a questionable assumption), intelligence agencies can just as easily break into all the servers (owned by a single party) and log the traffic themselves. Personally, I would be surprised if they haven't already done this for some providers -- why wouldn't they?

SSH is much slower than VPN, it can be an issue in some use cases.

Can you elaborate? i've found the opposite to be true, but then I am usually restricted by crappy ADSL bandwidth of 6mbit or less so i could be more sensitive to different aspects of "slow".

Note that sshuttle deconstructs the TCP packets before sending them over SSH which already uses TCP, it also performs differently to `ssh -D` and manages the buffer to prevent blocking behaviour over bandwidth limited connections:

       --no-latency-control
              Sacrifice latency to improve bandwidth benchmarks. ssh uses  re‐
              ally  big  socket  buffers, which can overload the connection if
              you start doing large file transfers, thus making all your other
              sessions  inside  the  same tunnel go slowly. Normally, sshuttle
              tries to avoid this problem using a “fullness check” that allows
              only  a  certain  amount of outstanding data to be buffered at a
              time.  But on high-bandwidth links, this can leave a lot of your
              bandwidth  underutilized.   It  also makes sshuttle seem slow in
              bandwidth benchmarks (benchmarks rarely test ping latency, which
              is  what  sshuttle  is trying to control).  This option disables
              the latency control feature, maximizing bandwidth usage.  Use at
              your own risk.

I've tried to transfer ~2GB file over SSH tunnel and VPN (on the same host), it was 3-4 times faster over VPN.