Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Identity management for WireGuard

lwn.net

Post reply on HN
Print view View original

61–70 of 107 posts

Re: Identity management for WireGuard

#61

Post by candiddevmike »

tptacek wrote: post #59
candiddevmike wrote: post #5

Things I wish WireGuard supported out of the box: - Logging of peer IPs when they initially connect or change (yes, you can do this with module flags, but it should come out of the box). - Tieing WireGuard private keys to a source IP. As far as I know the endpoint flag does not enforce an IP, a peer can use a different one and still connect. - More control over DNS resolution for endpoints. I want WireGuard to period…

These are all reasonable things to want and to track down, but it's worth noting that you in fact don't want WireGuard to support these things out of the box; the point of WireGuard is that it has exactly one job, and that job is integrated as deeply as possible with Linux networking. The things you're asking for are meant to be layered on top of WireGuard.

Don't tell people to not want the most basic amount of security implemented within the protocol. The rest of the Linux kernel networking stack logs more verbosely than WireGuard, and it supports packet filtering. If you had someone compromise your WireGuard mesh, you'd never know.

These are oversights, and it's OK for software to have them, but they need to get added in the future. Requiring users to layer this stuff on top of WireGuard creates security footguns. WireGuard's implementation isn't set in stone, it should be improved.

Re: Identity management for WireGuard

#62

Post by tptacek »

candiddevmike wrote: post #61
tptacek wrote: post #59

Earlier quoted context omitted.

These are all reasonable things to want and to track down, but it's worth noting that you in fact don't want WireGuard to support these things out of the box; the point of WireGuard is that it has exactly one job, and that job is integrated as deeply as possible with Linux networking. The things you're asking for are meant to be layered on top of WireGuard.

Don't tell people to not want the most basic amount of security implemented within the protocol. The rest of the Linux kernel networking stack logs more verbosely than WireGuard, and it supports packet filtering. If you had someone compromise your WireGuard mesh, you'd never know. These are oversights, and it's OK for software to have them, but they need to get added in the future. Requiring users to layer this stuff…

I think you're going to find that WireGuard "supports" packet filtering and logging in much the same way as the rest of the kernel does.

Re: Identity management for WireGuard

#63

Post by yardstick »

bongobingo1 wrote: post #40
candiddevmike wrote: post #17

Earlier quoted context omitted.

Your EC2 instance probably shouldn't be roaming to Russia though, right?

You already have to open your fw for wg traffic, doesn't seem too obnoxious to just allow/drop there.

Deny by default and Defense in depth are good security approaches in many organisations.

I may have a critical server that only comes from 1-2 known, static, IPs.

Repeat this for dozens of servers. Now treat each of these servers as third parties not under your control. I don’t want one of these third parties using a key that doesn’t belong to them. As a silly example, let’s say I send one third party the key for my super important server by mistake. I would prefer it simply wasn’t able to connect.

Re: Identity management for WireGuard

#64

Post by mathrawka »

Spooky23 wrote: post #46
bradfitz wrote: post #34

Earlier quoted context omitted.

(Tailscale engineer here) What's the bug? I hadn't heard about this. Metrics show no drop in iOS control plane connections.

Here’s the post i put up on the forum. https://forum.tailscale.com/t/difficulty-with-ios-tailscale-... Other posts had some troubleshooting guidance that wasnt effective. Note that it only failed on iOS. Still using it on my Debian boxes. If you could point me at anything I would be very grateful. I’m using some other VPN container now that i don’t like!

I had a similar issue, clearing history and website data in Settings > Safari and reinstalling fixed it for me. I may have rebooted the iPhone as well for good measure.

Re: Identity management for WireGuard

#65

Post by generalizations »

jacob019 wrote: post #39
generalizations wrote: post #31

Earlier quoted context omitted.

The feature parity I'm waiting for is L2 VPNs. Wireguard is strictly L3-only, and so far all I've seen are some custom hacks to tunnel L2 ethernet frames over wg.

Wireguard is L3 encryption. It's great because it's simple. Linus called it poetry. If you are bridging L2 over the Internet, then one way or another you're stuffing Ethernet frames into IP packets. Linux has built in L2 tunneling, sans encryption. I wouldn't call it a custom hack to open an L2 tunnel over wireguard. It's a one liner on each end. A configuration utility like wg-quick could be made to set it up for yo…

> I wouldn't call it a custom hack to open an L2 tunnel over wireguard

There's too many headers that are too big. If you do a simple L2 tunnel, you have three options: jumbo frames, packet fragmentation, or custom hacks. None are great.

> Linux has built in L2 tunneling, sans encryption

IIRC, because the extra header for the encryption layer pushes the MTU over 1500.

Re: Identity management for WireGuard

#66

Post by tssva »

tptacek wrote: post #56
tssva wrote: post #4

When Wireguard was 1st rolled out the smaller code base vs OpenVPN was touted as a feature. Now that 3rd party systems are available to bring feature parity with OpenVPN, it would be interesting to see a comparison of the size of the code base inclusive of these 3rd party systems. Not interesting enough for me to put forth the effort to do it but still interesting.

First, even with third-party code, WireGuard is going to be significantly smaller than OpenVPN (and significantly easier to audit). But more importantly, you can't just count lines of code as if they're all equivalent. There's a trusted core of code that is more important than the rest of the code, and WireGuard's trusted code is microscopic compared to OpenVPN. That's the right word in this case: "microscopic". It's…

"First, even with third-party code, WireGuard is going to be significantly smaller than OpenVPN (and significantly easier to audit)."

Do you have some evidence for that or is it just speculation?

"But more importantly, you can't just count lines of code as if they're all equivalent."

You're right but the Wireguard white paper conclusion claims an advantage for Wireguard based solely upon the lines of code needed to implement.

OpenVPN, Wireguard and IPsec all have their advantages and disadvantages. I have and will use all 3 where appropriate based upon them.

Re: Identity management for WireGuard

#67

Post by yardstick »

linsomniac wrote: post #14
Xylakant wrote: post #3

Earlier quoted context omitted.

Last time I worked with pritunl, it was based on openvpn. So unless that changed, it doesn’t fit the “for WireGuard networks” category.

It can use OpenVPN or Wireguard now. https://docs.pritunl.com/docs/wireguard

Interesting:

“The WireGuard private key is stored in the memory of the Pritunl client background service and also in the WireGuard configuration file. WireGuard uses a connection-less design and this private key could be used by an attacker to hijack the connection even if multi-factor authentication is used. In high security environments it is important to consider that OpenVPN connections with multi-factor authentication will not have these weaknesses. For this reason the server will quickly revoke WireGuard keys of inactive clients to limit the possibility of this occurring”

Does anyone know how others like Tailscale address this issue?

Re: Identity management for WireGuard

#68

Post by couchand »

candiddevmike wrote: post #18
couchand wrote: post #16

Earlier quoted context omitted.

> As far as I know the endpoint flag does not enforce an IP, a peer can use a different one and still connect. Yes WireGuard roams, which is the right behavior usually. What's your use case where an otherwise valid encrypted packet should be rejected based on source ip? Could you use ufw?

Mostly laziness. If I'm already giving WireGuard an IP via Endpoint, why not have it locked down to that by default? Isn't that what an end user would expect? Otherwise I have to put that IP in multiple places (WireGuard, nftables, etc).

The two most common topologies I've seen for WireGuard are:

1) Client-server, where the client is behind NAT and the server is publicly available at some DNS. The client specifies the server by hostname as the endpoint, and the server doesn't bother specifying an endpoint. Client roams when they switch networks, server roams when they roll over the server, everybody is happy.

2) Peer-to-peer, where the nodes are directly addressable by IP address, whether by public IP or private virtual private IP. In this case, the node dialing in sets an endpoint of the node being dialed, and the node being dialed doesn't bother specifying an endpoint. Thereafter node identity is verified by private key and nodes can fully roam within the firewall-limited subnet.

In every case I've seen, roaming by default is the right choice.

Re: Identity management for WireGuard

#69

Post by cpach »

candiddevmike wrote: post #61
tptacek wrote: post #59

Earlier quoted context omitted.

These are all reasonable things to want and to track down, but it's worth noting that you in fact don't want WireGuard to support these things out of the box; the point of WireGuard is that it has exactly one job, and that job is integrated as deeply as possible with Linux networking. The things you're asking for are meant to be layered on top of WireGuard.

Don't tell people to not want the most basic amount of security implemented within the protocol. The rest of the Linux kernel networking stack logs more verbosely than WireGuard, and it supports packet filtering. If you had someone compromise your WireGuard mesh, you'd never know. These are oversights, and it's OK for software to have them, but they need to get added in the future. Requiring users to layer this stuff…

See also:

https://news.ycombinator.com/item?id=33263746

Re: Identity management for WireGuard

#70

Post by amluto »

jacob019 wrote: post #9
tssva wrote: post #4

When Wireguard was 1st rolled out the smaller code base vs OpenVPN was touted as a feature. Now that 3rd party systems are available to bring feature parity with OpenVPN, it would be interesting to see a comparison of the size of the code base inclusive of these 3rd party systems. Not interesting enough for me to put forth the effort to do it but still interesting.

OpenVPN doesn't have awesome credential management baked in and the core networking code is an order of magnitude more complex, which is why the performance sucks compared to wireguard.

The complexity doesn’t even help it work well. For example:

https://web.archive.org/web/20210919013400/https://community...

OpenVPN is simply bad at networking irrespective of any security considerations. (Wireguard, AFAICT, does the right thing with regard to MTU and is much simpler as a result. OpenVPN seems to go out of its way to be wrong.)

Post reply on HN