If you wrap wireguard or build a layer on top of it, it's no longer wireguard that first listens to packets on public interface, it's your wrapper. The security properties of wireguard don't hold (potential for RCE before packets reach wireguard). That's a problem with projects like wstunnel or udp2raw.
You want wireguard to be the software that takes the packets first.
That's plain wrong. The first thing a normal wireguard faces is... the wild network of the Internet, with many servers and hordes of malicious agents. This is what makes is an "encrypted VPN", it's expected to withstand being transmitted by garbage media.
>potential for RCE before packets reach wireguard
There is no such thing as "rce packets". Moreover, every wireguard implementation has a different surface for RCEs (bugs), it's not a property of wireguard, it's a property of the implementation, of which there are at least three.
You didn't get it. It would be more clear if you implement it.
With these wrappers, peers also install and run wrapper and unwrapper services, to encapsulate udp packets into websocket frames and vice versa. For example, the software that proceses incoming packets from the internet could be wstunnel listening on 443/TCP. This layer converts the websocket TCP traffic to wireguard UDP, which wireguard would then decrypt. Wireguard could even listen to local host.
In popular implementations, this layer could have notable attack surface, particularly because it often provides additional features, such as obfuscation behind https, authentication, TLS client certificate validation, etc. I recall Debian has a minimal package which does only UDP to tcp parsing and conversion, which is written in C and not maintained. That layer could be insecure, and may lead to code execution on server before wireguard is even involved.
No, the parent commenter's logic is sounder than yours. WireGuard in its natural configuration can't trust incoming packets at all, so there's nothing to subtract by layering things on top of it.
Obviously, all software creates an opportunity for a bug, so even though this is pretty low-risk as attack surface goes, if you're making a choice between plain natural WireGuard and WireGuard wrapped in WebSockets, the "plain" version has marginally less attack surface.
But if your choice is between WireGuard wrapped in WebSockets or an entire new VPN protocol, clearly the new protocol drastically increases the attack surface.
In any case: wrapping WireGuard with something else does nothing at a design level to put WireGuard's security at risk. That's not how it works.
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.
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.
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.)
Wrapping-Unwrapping code is irrelevant to the security of wireguard.
Even if your wrapper-unwrapper is an outright remote shell without authorization, it would do nothing to compromise wireguard itself, as long as that shell has no sudo.
But in any case, that wrapper-unwrapper is usually just a packet rewriter, port-to-port, runs as a disabled user with no login privileges, no shell, and in a chroot. The only thing your RCE can do is to exit(1) the rewriter itself.
>My interpretation of OP is that they trust Wireguard’s code to be secure - random wrappers, somewhat less so.
There is not such thing as "wireguard code". Wireguard is a protocol, and "the security of wireguard" is the inability of the attackers to read the contents of the stream. This is not affected by the wrapper, because a wrapper is no more hazardous than the high seas, i.e. the Internet.
Speaking of implementation code. There are three wireguard implementations that I am aware of: Go, Linux, and OpenBSD. I am quite sure that none of those are bug-free, but adding a wrapper around wireguard packets has NO effect on the security of the implementation. The implementation is receiving packets from "something". This something can be either the net, or the wrapper, or even /dev/urandom
> because a wrapper is no more hazardous than the high seas, i.e. the Internet.
Unless that wrapper is running on the same machine as my Wireguard code - and then the wrapper becomes a potential weak point in the system.
I see where you're coming from and agree with you - in theory, a wrapper is usually thin and shouldn't impact the overall security posture of the system. But this is 2026. AI is regularly curb stomping any notion we had that we write good code and someone just discovered that my SSH server has gone the last decade allowing a login to anyone that pounds out enough 'A' into the password prompt [1].
Given that, I have a fair bit more trust that Jason's Wireguard code (the implementations you mention) correctly handles random packets off the Internet than a wrapper running in the same context.
Trivially, any layer on top very much influences the security. It usually runs on the same server, and in fact is often combined with wireguard code into a new VPN. In fact there are additional layers: firewall code, networking stack code, VPN, rest of OS. Just recently there was a critical vulnerability in Linux kernel TCP connection handling code. It wouldn't matter if OpenVPN listens to TCP connections on the same server: attacker may become root before meeting the VPN.
You can write a bare wapper in few hundreds lines of python, but it won't be robust to resume connections etc. The next step up is something like ProxyGuard referenced in this post, but look at repo to see the size of the code. It's this software that listens to open port, and if it has vulnerabilities, there will be remote code execution on the wireguard server. Then we have more featureful software such as wstunnel that are much bigger.
Most if not all software changes with platform. That's trivial.
I have dealt with this issue for a while.
Update: It seems you acknowledge the issue when you say in another comment "as long as the remote attacker does have sudo privilege". First, remote attacker may get root. Second, even if someone runs as a non root user on the same wireguard server, that's equivalent to that person bypassing the wireguard plus logging in as that user, which is worse. Authenticating to the server is an additional step that they would have to do even if they bypass the VPN.
This isn't true. You don't lose the security properties of WireGuard just because you wrap it in some other transport. There is no particular virtue to it "taking the packets first".
It would be the opposite. While old backdoors will be patched (if easier ones are not switched off or upgraded already), new far more sophisticated ones will be added with AI that only few states will have.
Shannon's entropy theory disagrees. No matter how good the best AI is, its ability to hide a backdoor is limited by the information density within the programming language, and the complexity of possible backdoors will plateau, allowing much lesser AIs to discover them. Consider that binary software is just a more dense form of code, too. A much less dense form, Javascript, makes finding backdoors easy because they all have to use obfuscation via base64 or something to avoid static analysis, which itself immediately draws suspicion.
This is a niche in which I do t exactly think speed of development and new bling is particularly important.
Either thy drop encryption and just become Google Suite competitor, or they stick to the original differentiator. Looks like they want both and the customers for each are different targets.
I backup my different devices to my NAS. The user is a restricted backup user seeing only their own directory. I obviously don't want my torrent computer gets root on my NAS.
I personally use openssh, but someone else may use tailscale SSH.
There are too many features, and lines of code (probably more than OpenVPN). I'm pretty sure there are all kinds of zero days in it, with this attack surface and feature set.
I use it extensively, and I would rather pay them a fee if they could review thr code.
A possibility is a lock down mode, disabling risky features.
I just want a VPN for connrctiviy, no taildrop, taildrive, SSH, funnel, services, DNS, node sharing, ...They are disabled in my admin console, but the code runs on my devices and they can be enabled by mistake.
A question. Taildrop enables unauthenticated input and doesn't even obey ACLs. I'm not quite sure about this, but couldn't malware in a low trust device send a file to my Synology NAS, which will then automatically process it for indexing things like thumbnail, leading to potential code execution? Why doesn't it obey ACLs, and why isn't the recipient approval needed before the file exits the sender's device? I use tags, but I'm the owner not the tag.
This is also how I feel about Tailscale and its popular alternatives. They do too much.
Does anyone know of a Tailscale alternative that sticks to the basics?
Something that’s just WireGuard but without the manual key exchange, and with Tailscale-like NAT hole-punching that falls back to using an oblivious relay?
I've been toying around with nebula, self host your lighthouse on a cheap VPS (which even if it gets hacked, the most it can do is lie about traffic, not lie about node certs). Basically you're just paying for the punchthrough (you may even be able to do some duckdns shenanigans?) The main issue is that updating nodes is a pain in the butt, which is the main advantage of tailscale IMO - centralized control plane. Keeps it simple.
I was trying to do some kind of insane workflow where you as the operator have a privileged hardware yubikey that admins the nodes when you plug it in, and the point is the nodes would self-propogate the changes outwards. I immidiately ran into classic issues with distributed security in distributed systems (even with only one central operator trying to admin everything). Tailscale is also a bit more secure in its oauth layer - with this architecture, you need to set proper time limits for expiring so one node compromise doesn't get access to the whole fleet. Couldn't really come up with better ideas than forcing the operator to reuse some kind of hardware key (the idea trying to be avoiding maintaining a cloud control plane as much as possible)
Fun foray but creating such a system requires a lot of expertise that I unfortunately lack
It is massively more complex than say Wireguard, because it was developed with "everything and kitchen sink approach", and even the standard de facto authors, Cisco, took good 20 years to stop having IPSec related vulnerability every few months (hell we just had one this year in Linux IIRC)
That doesn’t really help much if you want to connect an arbitrary number of nodes to eachother (each of which is potentially on an entirely different LAN), does it? That’s really the whole point of Tailscale.
Taildrop only works with devices that are yours, i.e. you can't send or receive anything from a device that's either tagged or owned by someone else. The only way malware is getting onto your NAS (via Taildrop) is if you're the one sending it there.
My Tailscale RCE[1] in 2022 involved forcing a device onto an attacker-controlled control plane, at which point your device is no longer "yours", and the fact that Taildrop is implemented in your client binary can be exploited. Chaining the bug to RCE would not have been possible against an ideal Tailscale with only the core feature set.
This was(/is?) a great write-up. Would the vulnerability enabled through Taildrop still work if the compromised machine was tagged or would the attacker's control of the... control plane make this additional safeguard redundant?
As a indie hacker(viber :) ) built mutiple tailscale based stuffs dated to the early days of tailscale, I like it but actually I do agree with you
There are too much features added now, perhaps some related to enterprise features because that must drive the revenue
Sometimes I am thiking perhaps they provide a light tailscale version but that seems not viable given the complexity now, headscale is great, but the OSS client still have plenty features, though they are gradually added feature based switch in the client source which I think is great, perhaps we can build a light version over it
This is also I do not think the tailscale-rs(which aim to rewrite tailscale with rust) will not be ready in a short time because too much (feature + cross platform) need to be tested
Re: Your question. Taildrop only works between devices in the same account. So if you don't put low trust devices in the same account as your NAS this is mitigated.
Tailnet owner may not trust all their devices to the same extent. Here is a concrete example.
I install tailscale on my cloud vps which I use for downloading torrents. I want my laptop to talk to this node, but I don't want this vm talk to my laptop, which is the whole purpose of ACLs. My ACL is deny by default, so that is great and easy to set. But now this node can still send arbitrary files to my laptop. If I don't remember to tag it, I'm vulnerable. If I do, there is still a window that this node can send me files until I tag it (I can't install tailscale to a tag).
Sending a file otherwise normally requires an app listening to a port, so taildrop permissions should be same as network permissions set by ACL.
BTW, last year or so tailscale advertised a position for someone to manage complexity of tailscale. Founder was talking about this issue. They seem to be aware of the problem.
Tags are a key part of managing ACLs. If you're concerned about an untrustworthy node on your tailnet, use tags. Even if you forget to add a tag to a newly added node (API keys can be set to automatically assume a tag when used fwiw), if your other devices are tagged then they're ineligible for taildrop.
% go run ./cmd/featuretags --min
ts_omit_ace,ts_omit_acme,ts_omit_advertiseexitnode,ts_omit_advertiseroutes,ts_omit_androidbin,ts_omit_androiddns,ts_omit_appconnectors,ts_omit_aws,ts_omit_bakedroots,ts_omit_bird,ts_omit_c2n,ts_omit_cachenetmap,ts_omit_captiveportal,ts_omit_capture,ts_omit_cliconndiag,ts_omit_clientmetrics,ts_omit_clientupdate,ts_omit_cloud,ts_omit_colorable,ts_omit_completion,ts_omit_completion_scripts,ts_omit_conn25,ts_omit_connreject,ts_omit_dbus,ts_omit_debug,ts_omit_debugeventbus,ts_omit_debugportmapper,ts_omit_desktop_sessions,ts_omit_dns,ts_omit_dnsresolvecache,ts_omit_doctor,ts_omit_drive,ts_omit_exitnodehealth,ts_omit_favorites,ts_omit_flashappliance,ts_omit_gro,ts_omit_health,ts_omit_hujsonconf,ts_omit_identityfederation,ts_omit_ipnbus,ts_omit_iptables,ts_omit_kube,ts_omit_linkspeed,ts_omit_linuxdnsfight,ts_omit_listenrawdisco,ts_omit_logtail,ts_omit_nattraversal,ts_omit_netlog,ts_omit_netstack,ts_omit_networkmanager,ts_omit_oauthkey,ts_omit_osrouter,ts_omit_outboundproxy,ts_omit_peerapiclient,ts_omit_peerapiserver,ts_omit_portlist,ts_omit_portmapper,ts_omit_posture,ts_omit_qrcodes,ts_omit_relayserver,ts_omit_remoteconfig,ts_omit_resolved,ts_omit_routecheck,ts_omit_runtimemetrics,ts_omit_sdnotify,ts_omit_serve,ts_omit_serviceclientprefs,ts_omit_ssh,ts_omit_synology,ts_omit_syslog,ts_omit_syspolicy,ts_omit_systray,ts_omit_taildrop,ts_omit_tailnetlock,ts_omit_tap,ts_omit_tpm,ts_omit_tundevstats,ts_omit_udptransport,ts_omit_unixsocketidentity,ts_omit_useexitnode,ts_omit_useproxy,ts_omit_usermetrics,ts_omit_useroutes,ts_omit_wakeonlan,ts_omit_webbrowser,ts_omit_webclient
> FWIW you can rebuild tailscaled to omit all the optional stuff:
It would also cost Tailscale nothing to build and ship a minimised version alongside the bloated version. Thereby making it officially supported option.
Because you just know support will start finger-pointing and asking you to install the bloated version if you tell them you're having an issue with your home-compiled minimised version ....
And what will happen to all these software engineers who are laid off, and to massss who are graduating in CS (because the same CEOs told them it's a good carrier)?
France also regulates encryption in applications. Some percentage of apps are not available in France, because apps don't comply with the rules imposed by bureaucrats or more often developers find procedures cumbersome or unfamiliar
You want wireguard to be the software that takes the packets first.
reply