Comment by tialaramex | Hacker News Reader

Comment by tialaramex | Hacker News Reader

> The peer private key is generated on the server, which is technically not as secure as generating it on the client peer and then providing the server the public key

"Not as secure" means specifically this punts all the actual security of the system.

This is one of the sad but predictable thing with designs like WireGuard that themselves decided to punt this hard problem (you can also see it in OpenVPN [edited: Let's blame an early morning for me writing OpenSSL there] and with the same consequences). So in one sense it isn't your fault - Jason knew this was hard but left it for you to solve anyway, and predictably you didn't.

But of course for the end user the practical result is that they maybe don't get the security benefits they were told were available in WireGuard.

My crystal ball is cloudy but I'd guess that one possible future for WireGuard is that it gradually grows a reputation for insecurity not because WireGuard the protocol is bad but because the way it's used has meant almost invariably bad guys get private keys they shouldn't have.

The irony being that this is what the IPSec people have been arguing because WG externalities all the messy real-world bits which now have to be solved again.

But I think your criticism is overly harsh. A lot of the use-cases for WG are to connect a group of systems that are mutually trusted. But even if they aren’t, the sever potentially knowing your single-use private key doesn’t matter as much as your making it seem because all an attacker can do is authenticate as you. Who cares at that point when the server is compromised.

Some prior art. The standard OepnVPN setup on pfSense stores the CA keys and all client keys on the server.

The history of practical encryption has been largely about solving the "messy real-world bits".

I am emphatically not saying here that WG is a step backward. But what I had hoped to see - either from Jason or from somebody else in that community - were practical approaches to actually deploy this safely in real environments people have.

Let me give you a small not very related example that made me smile recently of how to make security usable:

Magic wormhole will cheerfully help do SSH public key setup for a new device that needs access.

Normally this is a messy real-world problem. The SSH public key for a new laptop, or a phone, or whatever needs to get authorized for access to some system. As a public key it isn't secret, but the correct key must be installed or you'd be subject to a sophisticated MITM. Unlike the server authentication there is no provision for TOFU and it's unclear how that should work anyway. SSH keys are too long to just read them out comfortably, secure messaging platforms add clumsy extra steps (copy, paste)...

But Magic Wormhole fits the gap pretty nicely. You run one end of the wormhole on the machine where the key is to be installed, and the other on the machine that has the key pair, secured with a trivial human memorable passphrase like '6-candle-cheesegrater-horse' and the result is simple but safe†.

† I've argued Wormhole security thresholds should be higher mostly for PR reasons, but it's not a deal breaker and you can doubtless find my rambling about that if you care.

> "Not as secure" means specifically this punts all the actual security of the system.

In my opinion, not quite; the peer private key only exists on the server for a short amount of time which somewhat mitigates the problem.

I agree it's not ideal but it is convenient, and a good balance for the average user in my opinion. I will support specifying a public key as part of the `add` command soon. See https://github.com/naggie/dsnet/issues/8 (also, see the FAQ)

Thanks for the feedback

Reply on news.ycombinator.com