WireGuard is a better, safer protocol than mTLS. If you can use WireGuard, that's what you should use (often you can't, because you don't want IP addressing between your components).
I'm enthusiastic about WireGuard but I'm dubious about the "forklift" approach you describe. Actually, more seriously, I doubt in most cases that systems to be forklifted were truly secure originally and so while I don't think using WireGuard makes that worse, it may mean an opportunity is missed to fix more serious problems.
Presuming that by mTLS you mean mutually authenticated TLS, I don't see it as a good fit for internal systems - to me (as someone who has implemented mutual auth to considerable success) it's best where you have B2B applications, because you've got the three distinct parties that make a PKI worthwhile. Whenever I see a PKI in which all three of the parties are essentially identical I cringe, e.g. I keep seeing OpenVPN setups where one person runs the CA, runs the VPN server and mints all the private keys - the PKI is pure theatre in this approach, it makes no difference to anything.
WireGuard is just a transport protocol, so of course you could use it in place of SSL/TLS if you wanted. Interesting though, and I prefer it to SSL/TLS because X509 certs suck.
They're somewhat complimentary. I've got both running along side each other. Wireguard has much better throughput, but tinc guarantees a fully connected network (each node can reach every other node).
I wish wireguard could accept overlapping AllowedIPs ranges, appear as an L2 interface, and take a nexthop from the system routing table. Imagine multiple hosts each providing egress to each other - tinc can do this topology when setup to act as an ethernet segment. But wireguard is so trivial to setup, it's easy enough to run a parallel instance for each horizon.
And what I like about Wireguard is that you can't port scan for it. The protocol is designed in such a way that the wireguard server won't respond unless you know the right key.
Is there a significant difference between doing HTTP over TLS vs HTTP over WireGuard?
I enjoy WireGuard and it's tooling but in this case TLS seems like the better, battle tested option without any significant downsides if all you are doing is HTTP anyways...
I don't think the comparison to Wireguard is apples-to-apples. Wireguard implements it's own semi-custom cryptosystem (Noise) whereas subnet rides on top of Go standard TLS implementation. So depending on how you view things, Wireguard is either much simpler (if you compare to the whole TLS stack) or much more complex (if you assume Go TLS to be reliable/trustworthy)
Every connection you make to a remote service "exfiltrates data". Modern TLS is just as opaque to middleboxes as WireGuard is, unless you add security telemetry directly to endpoints --- and then you don't care about the network anyways, so just monitor the endpoint.
The reason you'd use WireGuard rather than TLS is that it allows you to talk directly to multiple services, using multiple protocols (most notably, things like Postgres and Redis) without having to build custom serverside "gateways" for each of those protocols.
I started off using tinc before wireguard existed, and now use both. Tinc provides a guaranteed full connectivity graph with indirect routing, nat punching, and local subnet discovery as needed. Wireguard is much more performant (eg it can be used to secure nfs without kerberos). Eventually someone will write a daemon for wireguard that provides tinc's features, but until then they are complimentary. I use wireguard between routers to carry full subnets, and tinc is setup on individual hosts to provide fallback access.
This is less important although useful in some cases. The more important thing is outbound - since Wireguard is layer 3, in the routing table you can't specify a peer to send the packet to like you can with ethernet, and it has to choose one using AllowedIPs.
I would say it really comes down to the use case. If you're already using TLS and have the infrastructure for key management, issuing certs, etc. It's not worth replacing.
To me, where WireGuard comes in is for services that aren't traditionally encrypted, or where an extra layer of security is desired.
The example case that we've seen a few times is cluster DNS. The DNS traffic internal to the cluster is just plain DNS, meaning it leaks internal information and can be tampered with on an untrusted network. Even though CoreDNS does support DNS over TLS, it's a large effort to update clients in some organizations, that is better spent elsewhere.
This is where we see the opportunity for WireGuard, is ensuring all internal traffic is encrypted. For taking applications where the security model traditionally requires a secure network, and allowing them to be forklifted into a kubernetes cluster that provides those capabilities. I'm not saying this is an ideal model over using mTLS for every connection, just not everyone has what's needed to deliver mTLS everywhere.
Unfortunately, we do lose the identity features that TLS offers in the x509 certs. Nothing prevents running TLS for services that need it though on top of the WireGuard network.
So like everything else, I think there are pros and cons to both approaches, and it depends on what applies to the specific application.
reply