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