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?
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.
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.
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.
>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.
Indeed. That's how the WireGuard handshake works, partly to avoid abuse/spam.
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?
I actually came to post this, I am to confused, what does exactly do?!
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.
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.
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.
Why stop there? Give use Wireguard certificate auth already!
Because then it would be DTLS.