In your implementation, you wrote software that listens to public internet, takes as input websocket traffic and outputs UDP. Right there, there is potential for vulnerabilities and code execution. This piece has nothing to do with software that would next process UDP.

That's why wireguard over TCP is not as secure as wireguard UDP.

▲

tptacek 2 hours ago | parent [-]

This makes no sense. It's marginally less safe to accept UDP packets than TCP packets, for which you at least need to complete a 3WH to deliver frames. I don't think you've thought this through.

▲

codethief 2 hours ago | parent [-]

IIUC the parent's point is that if you first have to unwrap incoming, say, HTTPS traffic to obtain the Wireguard UDP packets, that unwrapping code might contain vulnerabilities, so an attack compromising the machine Wireguard is running on might occur before the packets ever reach the Wireguard implementation. From where I stand that's a somewhat academic scenario, though. (Unwrapping correctly & safely is usually not that difficult. Just don't use a memory-unsafe language for parsing & unpacking maybe.)

	▲	tptacek an hour ago \| parent [-]
		I address that at length 2 comments back.