Rendered at 08:05:53 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
cube00 11 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 3 hours ago [-]
Indeed. That's how the WireGuard handshake works, partly to avoid abuse/spam.
anonymousiam 8 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 7 hours ago [-]
I actually came to post this, I am to confused, what does exactly do?!
mlhpdx 3 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 2 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.
tosti 8 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 3 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.
pamcake 11 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.
It's different than the VPN use case where you absolutely want to lock down access to known peers.