Rendered at 16:29:38 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
cube00 20 hours ago [-]
>the Listener rejects any handshake from an unknown key.
It never responds, there's no indication of rejection.
The client can't even be sure a service is actually there or they've hit a default drop firewall rule.
mlhpdx 11 hours ago [-]
Indeed. That's how the WireGuard handshake works, partly to avoid abuse/spam.
anonymousiam 16 hours ago [-]
This is confusing to me, and I'm not a novice to WireGuard.
WireGuard is a layer-3 protocol. Given that WireGuard does not natively support DHCP or dynamic internal IP allocation within its encrypted tunnels, and it instead relies on static tunnel IP configurations (Address and AllowedIPs for each pre-registered client), how would a new unregistered client be assigned an IP address within the encrypted subnet?
tamimio 15 hours ago [-]
I actually came to post this, I am to confused, what does exactly do?!
mlhpdx 11 hours ago [-]
The confusion is understandable. Fundamentally, all that's going on is that UDP Gateway is performing the NOISE_IK handshake and ChaCha20-Poly1305 encryption to establish a tunnel. It does nothing with the encapsulated traffic other than deliver it (raw or decapsulated) to the configured destination (Lambda, S3, etc.).
It's a primitive for building secure, but open to any client (any peer public/private key will be accepted).
To use it as a VPN would require write a complex Lambda on the AWS end. But that isn't the point.
The point is providing very efficient encryption for UDP from the edge to the cloud, or between machines. It's lighter weight and more reliable than DTLS because of the lack of sequence number and retry.
That's it.
anonymousiam 10 hours ago [-]
Okay, so you're saying that it's not a complete WireGuard implementation and not functional. Every WireGuard endpoint must have an IP address (or subnet) on the encrypted subnet. If an endpoint doesn't have one, WireGuard cannot route traffic to that endpoint.
You said the handshake is establishing a tunnel, and that it is delivering raw traffic, but how is that possible in a L3 environment that uses IP addresses to determine route(s) to an endpoint? When you refer to "encapsulated traffic", you probably mean traffic from the unregistered endpoint to a known WireGuard server, This would give the known WireGuard server the public IP of the unregistered endpoint, but unless the WireGuard server has an IP address for the unregistered endpoint's encrypted L3 subnet, no traffic will ever flow in the other direction.
A few years ago, I had an idea for a secure way for two WireGuard endpoints to find each others' public IP address, which I have not yet implemented, but even in that environment both endpoints would need the keys and private IP/subnet addresses of their peers in order to communicate.
Some background on my WireGuard experience:
I've set up a lot of WireGuard systems and have even done some WireGuard demonstrations for government research purposes (over five years ago, before I retired).
Right now I'm maintaining (for myself, my family, some former consulting clients, and two of our security systems) a dual-stack multi-point WireGuard network with three cloud servers, and about 30 endpoints scattered across four physical locations and five mobile devices. I even set up some kludgy scripts so that two of the locations using dynamic IP can communicate directly point-to-point with each other, and fall back to one of the cloud-based WireGuard routers to re-sync if/when one of their public IP addresses changes. Direct point-to-point communication cuts latency in half and reduces my cloud data fees.
mlhpdx 1 hours ago [-]
Well, here are a couple things to do with this:
I have a fleet of small battery powered temperature sensors that send readings to a backend built with it. On the sensors, I’m using the vanilla WireGuard-ESP library to connect over Wi-Fi to the backend (full tunnel). So the IP for the device is assigned like normal, the the tunnel is established. The sensor also needs to pull time (NTP) over the tunnel. So it talks to two different “IPs” that are completely virtual. At the other end of the tunnel the packets are inspected in the Lambda and if they match one of the two magic IPs, things happen (temperature stored or NTP response). The Lambda function does all that work (there is no real NTP server).
Another example is what I call CoAP/wg where raw CoAP requests are sent by a client application. By raw I mean what goes over the tunnel isn’t encapsulated IP, it’s just plain CoAP. In that case the backend just handles it like any other CoAP implementation would since the UDP Gateway terminates the encryption/tunnel. This isn’t a tunnel in the networking sense but it uses the same backend as the temp sensor example.
It’s a weird tool, but a really nice one IMHO.
mlhpdx 1 hours ago [-]
> both endpoints would need the keys and private IP/subnet addresses of their peers in order to communicate.
That’s how every other implementation works. It’s not a requirement of the protocol though, and that inspired this tweak in my implementation.
FWIW, it still allows configuring known peers separately from unknown ones.
Sorry for the double reply, I had meant to address that in the first.
anonymousiam 17 minutes ago [-]
Thanks for your explanations. I recognize that you're offering this as a product within the AWS ecosystem, but because it's an evolution of WireGuard, which has a GPLv2 license, you should probably provide some way for users to obtain your source code, unless you've acquired a separate license directly from Jason Donenfeld.
VCFundedGenYer 3 hours ago [-]
I don't understand why you would want to over-complicate WireGuard like this.
The default setup is perfect - you set up your profiles, and the server doesn't respond if you try to connect with an invalid one. Any other addon to this is just reducing security.
Why muddy that perfect process with this?
mlhpdx 1 hours ago [-]
How is this making it more complicated?
The “why” is pretty simple: the WireGuard protocol is really nice and makes a better protection layer than DTLS in my opinion.
All this implementation does that is different is make hosting public services (accessible to unknown peers) possible.
tosti 17 hours ago [-]
I think this would nerf wireguard similarly to how a "null" encryption effectively nerfed IPSec. Fine for a specific use case (debugging comes to mind) but should never be upstreamed imho.
mlhpdx 11 hours ago [-]
That's not the case at all. The security here is more like HTTPS/TLS with the client not really being validated (just the server). The encryption remains just as strong as if the peers we're locked down.
It's different than the VPN use case where you absolutely want to lock down access to known peers.
tosti 3 hours ago [-]
I don't see the contradiction here.
pamcake 19 hours ago [-]
Why stop there? Give use Wireguard certificate auth already!
It never responds, there's no indication of rejection.
The client can't even be sure a service is actually there or they've hit a default drop firewall rule.
WireGuard is a layer-3 protocol. Given that WireGuard does not natively support DHCP or dynamic internal IP allocation within its encrypted tunnels, and it instead relies on static tunnel IP configurations (Address and AllowedIPs for each pre-registered client), how would a new unregistered client be assigned an IP address within the encrypted subnet?
It's a primitive for building secure, but open to any client (any peer public/private key will be accepted).
To use it as a VPN would require write a complex Lambda on the AWS end. But that isn't the point.
The point is providing very efficient encryption for UDP from the edge to the cloud, or between machines. It's lighter weight and more reliable than DTLS because of the lack of sequence number and retry.
That's it.
You said the handshake is establishing a tunnel, and that it is delivering raw traffic, but how is that possible in a L3 environment that uses IP addresses to determine route(s) to an endpoint? When you refer to "encapsulated traffic", you probably mean traffic from the unregistered endpoint to a known WireGuard server, This would give the known WireGuard server the public IP of the unregistered endpoint, but unless the WireGuard server has an IP address for the unregistered endpoint's encrypted L3 subnet, no traffic will ever flow in the other direction.
A few years ago, I had an idea for a secure way for two WireGuard endpoints to find each others' public IP address, which I have not yet implemented, but even in that environment both endpoints would need the keys and private IP/subnet addresses of their peers in order to communicate.
Some background on my WireGuard experience:
I've set up a lot of WireGuard systems and have even done some WireGuard demonstrations for government research purposes (over five years ago, before I retired).
Right now I'm maintaining (for myself, my family, some former consulting clients, and two of our security systems) a dual-stack multi-point WireGuard network with three cloud servers, and about 30 endpoints scattered across four physical locations and five mobile devices. I even set up some kludgy scripts so that two of the locations using dynamic IP can communicate directly point-to-point with each other, and fall back to one of the cloud-based WireGuard routers to re-sync if/when one of their public IP addresses changes. Direct point-to-point communication cuts latency in half and reduces my cloud data fees.
I have a fleet of small battery powered temperature sensors that send readings to a backend built with it. On the sensors, I’m using the vanilla WireGuard-ESP library to connect over Wi-Fi to the backend (full tunnel). So the IP for the device is assigned like normal, the the tunnel is established. The sensor also needs to pull time (NTP) over the tunnel. So it talks to two different “IPs” that are completely virtual. At the other end of the tunnel the packets are inspected in the Lambda and if they match one of the two magic IPs, things happen (temperature stored or NTP response). The Lambda function does all that work (there is no real NTP server).
Another example is what I call CoAP/wg where raw CoAP requests are sent by a client application. By raw I mean what goes over the tunnel isn’t encapsulated IP, it’s just plain CoAP. In that case the backend just handles it like any other CoAP implementation would since the UDP Gateway terminates the encryption/tunnel. This isn’t a tunnel in the networking sense but it uses the same backend as the temp sensor example.
It’s a weird tool, but a really nice one IMHO.
That’s how every other implementation works. It’s not a requirement of the protocol though, and that inspired this tweak in my implementation.
FWIW, it still allows configuring known peers separately from unknown ones.
Sorry for the double reply, I had meant to address that in the first.
The default setup is perfect - you set up your profiles, and the server doesn't respond if you try to connect with an invalid one. Any other addon to this is just reducing security.
Why muddy that perfect process with this?
The “why” is pretty simple: the WireGuard protocol is really nice and makes a better protection layer than DTLS in my opinion.
All this implementation does that is different is make hosting public services (accessible to unknown peers) possible.
It's different than the VPN use case where you absolutely want to lock down access to known peers.