Problem
Securely connect applications through open networks
TLS/SSL
Managing TLS/SSL in application layer is tricky:
- need to manage root CA
- need to implement keys rotation
- differs from service to service
- and it's not always available
- no support in
- zookeeper for server2server TLS
- clickhouse to zk connection
Wireguard
by Jason A. Donenfeld aka zx2c4
Goal
make a VPN that avoids the problems in both crypto and implementation
What is WireGuard?
- Layer 3 secure network tunnel for IPv4 and IPv6.
- Opinionated.
- Lives in the Linux kernel, but cross platform implementations are in the works.
- Modern conservative cryptographic principles.
- Emphasis on simplicity and auditability.
- Authentication model similar to SSH’s authenticated_keys.
- Replacement for OpenVPN and IPsec.
Easily Auditable
- OpenVPN – 116,730 LoC
- StrongSwan – 405,894 LoC
- WireGuard – 3,904 LoC
Simplicity of Interface
- WireGuard presents a normal network interface:
# ip link add wg0 type wireguard
# ip address add 192.168.3.2/24 dev wg0
# ip route add default via wg0
# ifconfig wg0 …
# iptables –A INPUT -i wg0 … - Everything that ordinarily builds on top of network interfaces – like eth0 or wlan0 – can build on top of wg0.
Simplicity of Interface #2
- The interface appears stateless to the system administrator.
- Add an interface – wg0, wg1, wg2, … – configure its peers, and immediately packets can be sent.
- Endpoints roam, like in mosh.
- Identities are just the static public keys, just like SSH.
- Everything else, like session state, connections, and so forth, is invisible to admin.
Cryptokey Routing
- The fundamental concept of any VPN is an association between public keys of peers and the IP addresses that those peers are allowed to use.
- A WireGuard interface has:
- A private key
- A listening UDP port
- A list of peers
- A peer:
- Is identified by its public key
- Has a list of associated tunnel IPs
- Optionally has an endpoint IP and port
Wireguard
By Mikhail Shirkov
Wireguard
- 524