Why Not Use TLS to Connect to the Database Instead of WireGuard?
目录
Software translation
This is the second blog post in the “My Experience Sharing Series on High Throughput http2 Server Optimization”.
The previous blog mentioned not using TLS to connect to the database and instead using WireGuard. This article provides a detailed explanation of why this is the case.
Number of configurations
TLS works at the application layer, while WireGuard works at the network layer, resulting in configuration differences.
At the application layer, it means that each database instance needs to modify the configuration file to configure it, while at the network layer, it means that only the database needs to be configured on the host.
So, if n databases and m database hosts are used, TLS needs to be configured n times by m; Using WireGuard only requires m configurations.
Taking MySQL+Redis as an example, if there are 5 hosts, it means that TLS needs to be configured 10 times, while WireGuard only needs to be configured 5 times.
Moreover, with TLS, production environments typically have their own CA, self issue certificates, and configure automatic certificate updates, which can be more complex.
Quantum security
The current standard TLS1.3 does not provide quantum security, and both RSA and ECC are quantum insecure.
Although quantum secure key exchange algorithms such as ML-KEM hybrid X25519 have been offered since go1.24, they are currently not supported in mainstream TLS databases.
Although the Curve25519 used by WireGuard does not provide quantum security, WireGuard supports PSK. By providing a 256 bit randomly generated key, even if an attacker can crack Curve25519 (such as through a quantum computer), they still need to crack PSK to decrypt the traffic. Similar to AES256, quantum security is sufficient, and symmetric keys themselves are quantum secure. Ultimately, it makes WireGuard with PSK quantum secure.
Anti intrusion analysis
Now, by deploying the database on a cloud server and using WireGuard, the database can be completely on the intranet without being exposed to the public network, reducing the attack surface.
WireGuard has provided encryption as an alternative to TLS. In real production environments, effective authentication can be achieved by configuring dedicated point-to-point routing from each client to the database, assigning dedicated usernames, passwords, and permissions.
If a node using a database is compromised and listens to internal network traffic, it can also steal TLS client certificates and impersonate clients on the spot.
So using WireGuard with supporting measures and using TLS to connect to the database also has good anti intrusion capabilities.
Scalability
In situations where there are a large number of nodes, such as hundreds or even more nodes connected to the database, the operation and maintenance costs of WireGuard with supporting measures are higher, because IP allocation, setting dedicated usernames, passwords, and permission assignments need to be repeated every time a node is added, especially when the WireGuard configuration file of the database needs to be modified every time a node is added.
TLS, on the other hand, can automatically allocate and update certificates through self built CAs and improved toolchains, achieving dynamic node growth.
Suggestion
WireGuard with accompanying measures is a better choice for connecting to databases on a small scale.
As the number of nodes increases, the operational costs of using TLS will be evenly distributed due to the scale, making this solution more suitable.
Combining WireGuard and TLS is always possible, but it introduces more opportunities for errors to reduce availability, which is not worth it on a small scale.