Bad practices all around
Bad practices all around
Posted Jul 10, 2024 2:02 UTC (Wed) by atnot (subscriber, #124910)In reply to: Bad practices all around by mirabilos
Parent article: Offload-friendly network encryption in the kernel
- vast amounts of complexity, mostly from bad design decisions that they really don't have the resources to fix
- no data plane/control plane separation. Both in the code and the network. One channel is used for everything. A lot of downstream issues ultimately stem from this.
- single threaded
- lots of obsolete and broken modes and features. Because there's no good layer separation nor plugin system, these end up infecting the whole program with weird code paths that were necessary to fulfill some companies weird requirement at some point and can never be removed because nobody knows who even uses any of it (we contributed at least two of those to the list, oops)
- not really a protocol as much as a client and a server that happen to be bug compatible with each other. There is little to no information about how anything is actually supposed to work, at any level.
- the configurations suck, auth sucks, there is no way to reconnect without reauthenticating, and lots of other annoying papercuts.
- openvpn3 solves some of this except it doesn't and you can't use it
To the stuff that actually matters for this use case:
- It is completely infeasible to implement a protocol as weird and complex as openvpn in hardware
- it is barely feasible to implement it in the kernel. There is openvpn-dco but it has tons of asterisks and is extremely unlikely to ever be accepted upstream.
- it is not particularly fast, or built to be able to be made fast
- it's also just way overkill. The niceties of openvpn are mostly in the management features. If you're just going to be using a custom system to ship around all of the keys anyway, you may as well just use wireguard which doesn't have any of these disadvantages.
Posted Jul 10, 2024 12:13 UTC (Wed)
by mbunkus (subscriber, #87248)
[Link] (2 responses)
- with a lot of setups establishing the connections takes quite a lot of time, as in upwards of ten seconds, often enough more like 20 (with Wireguard connections are instant as there simply is no handshake/establishing of a connection necessary before sending data)
- most companies chose to run OpenVPN in TCP mode, severely tanking the performance of any kind of data transfer over it (tunneling TCP over TCP is really bad due to how scaling works in TCP); the argument is that it's easier to get through middleboxes. This gets much, much worse if you're running over higher latency links. Not that OpenVPN-via-UDP is the fastest thing out there: in pretty much all speed comparisons I've seen OpenVPN always comes in after Wireguard & IPSEC.
- if you want to change several of the protocol options on the server side, you must re-deploy all client configs (think of using different compression methods, changing the MTU etc. etc.). Same goes when you have to re-create the certificate CA you're using, e.g. due to having chosen poorly earlier in your life when you created your CA with SHA-1 digest. This cannot be done incrementally. It's a "everyone must upgrade at once" situation.
- OpenVPN relies on the OS's SSL library (most often: OpenSSL) for encryption. In practice this means that upgrading your machine's OS might suddenly make your OpenVPN tunnel not work anymore, as new OpenSSL versions often disable/deprecate older digests or encryption methods. Sometimes you can insert some arcane options into your OpenVPN options to make your OpenSSL still accept them ("tls-cipher "DEFAULT:@SECLEVEL=0""). If not, see above: changing protocol options on the server side, re-create & re-distribute all client configs.
- OpenVPN sometimes changes their configuration format in incompatible ways. As the provider of config files for your clients/customers/co-workers, you suddenly have to offer several different ones that work on certain ranges of OpenVPN clients.
The whole _management_ side of OpenVPN is what really sucks for me.
Posted Jul 10, 2024 16:02 UTC (Wed)
by mirabilos (subscriber, #84359)
[Link]
I used to have a full setup of this and want to put it up again, so I know it works and how it works and how I have to configure it, and it’s compatible enough.
As far as I can tell, for this use case, it’s just possible annoyances, not something that absolutely speaks against it. Speed is also not much of an issue, given German internet.
But I can see how that would be more than annoying at company scale, yes.
Posted Jul 11, 2024 9:50 UTC (Thu)
by hkario (subscriber, #94864)
[Link]
that's just something that comes with the territory, if you're on market for something like two decades, the cryptographic best practice will change under you. If you want to continue to use configurations from 20 years ago that means you have to tell OpenSSL that you want to use long obsolete crypto.
Same with ipsec, just because you can use it with IKEv1, doesn't mean you should.
Once wireguard is on the market for 20 years, it will have arcane configuration options too, or it won't be used any more.
In my experience, I did try setting up IPsec tunnels in two completely different environments (though both with static public IP to a dynamic IP behind a not-forwarded NAT, all with resolvable DNS names though), and the IPsec tunnels were super unreliable, reconnecting worked once every 10 times or so. If the connection went down it basically stayed down. After switching both to OpenVPN they just were rock solid.
More OpenVPN drawbacks
More OpenVPN drawbacks
More OpenVPN drawbacks