To be honest WireGuard over Shadowsocks is neither common nor recommended, coz essentially it's TCP-over-TCP which will wreak havoc on TCP congestion control.
Unless you mean WireGuard over Shadowsocks UDP transport, but that is even less common.
Actually I'd rather WireGuard adopt some obfuscation mechanisms, but as Jason stated it's a non-goal and the focus is to get WireGuard into mainstream OS kernels. So the only hope is to provide some obfuscation transport underneath.
Tunneling WG over SS would be inefficient for obvious reasons. Maybe there should be a more lightweight solution.
almost all DPI software recognize the wireguard handshake.
Why should that matter? How does the DPI software get your keys? Isn't WireGuard data flow completely opaque to anyone or anything between endpoints?
If the DPI software blocks WireGuard packets, that's an entirely different discussion. It gets into the area of "technical solutions" to fight "administrative policy".
> It gets into the area of "technical solutions" to fight "administrative policy".
Yes, that's exactly the point. Sometimes that's the best course of action available to you. If the userspace implementation were to be deprecated that could pose difficulties.
Why would it be an issue? Can't you specify localhost as the endpoint and use the proxy to send it where it needs to go? What is the difference between the implementations?
I like to visualize networks as a series of tubes in my head. Maybe I'm misunderstanding something but I'm imagining a kernel driver that acts as a separate network interface proxying to localhost as a klein bottle[0] esque object
Unfortunately the recent popularity means that almost all DPI software recognize the wireguard handshake.