Wrap lines

pages/about-us/news/2020/wireguard.md

@@ -15,20 +15,21 @@ being affected by most of the ones that have appeared in the last years.
 
 Since a few years there is a newcomer to the free software VPNs:
 [WireGuard](https://wireguard.com/). WireGuard uses nice modern cryptography
-primitives, a pretty simple protocol and has a small code base. This makes it a very
-fast VPN and probably less prone to security issues.
+primitives, a pretty simple protocol and has a small code base. This makes it a
+very fast VPN and probably less prone to security issues.
 
 If WireGuard is so great why don't we ditch OpenVPN and use WireGuard instead?
 WireGuard is great, but (yes, there is always a "but") it wasn't designed for
 our use cases and it is not trivial to make it work for us.
 
 WireGuard uses UDP, which is great for speed. But many of our users are in
-networks that don't allow UDP traffic and for them to be able to connect we need 
-the VPN to support TCP. We are currently using OpenVPN on TCP mode, but our plan 
-for the future is to dynamically use UDP if available and if not to fall back to 
-TCP.
+networks that don't allow UDP traffic and for them to be able to connect we
+need the VPN to support TCP. We are currently using OpenVPN on TCP mode, but
+our plan for the future is to dynamically use UDP if available and if not to
+fall back to TCP.
 
-Some time ago there was a discussion about [TCP support in the wireguard mailing 
+Some time ago there was a discussion about [TCP support in the wireguard
+mailing
 list](https://lists.zx2c4.com/pipermail/wireguard/2018-March/002496.html), with
 proposed solutions like using
 [ssf](https://github.com/securesocketfunneling/ssf),
@@ -37,19 +38,19 @@ proposed solutions like using
 a bit hacky, one extra moving piece that can break.
 
 Another problem is that WireGuard doesn't provide dynamic IP allocation. We
-don't know in advance who will be connected to assign static IPs to each client. 
-We rely on OpenVPN to do it dynamically each time a client connects. In WireGuard
-we would need to build some tooling around to do all this IP assignment without 
-the service operators getting the possibility to correlate users and clients to 
-IPs.
+don't know in advance who will be connected to assign static IPs to each
+client.  We rely on OpenVPN to do it dynamically each time a client connects.
+In WireGuard we would need to build some tooling around to do all this IP
+assignment without the service operators getting the possibility to correlate
+users and clients to IPs.
 
-Besides all these technical issues there is a security issue, the authentication 
-protocol of WireGuard is not Forward Secret. That means an observer recording 
-all conversations only need to wait until the server long term secret key gets 
-compromised to be able to figure out which client produced each connection. Let 
-me remark, this doesn't mean that the attacker can decrypt the traffic, they 
-only see the authentication key, so they can pinpoint a client being the same in 
-different connections.
+Besides all these technical issues there is a security issue, the
+authentication protocol of WireGuard is not Forward Secret. That means an
+observer recording all conversations only need to wait until the server long
+term secret key gets compromised to be able to figure out which client produced
+each connection. Let me remark, this doesn't mean that the attacker can decrypt
+the traffic, they only see the authentication key, so they can pinpoint a
+client being the same in different connections.
 
 While this is a flaw, it is clearly an improvement over TLS 1.2 with client
 certificates, which we are currently using with OpenVPN. Previously to TLS 1.3
@@ -60,10 +61,10 @@ track the users. We do minimize that by rotating the cert frequently and we are
 preparing a migration to TLS 1.3, that solves this problem by transferring the
 cert over a forward secret channel.
 
-The dynamic IP allocation and the lack of forward secrecy for client identifiers 
-are being worked on in a separate tool named
-[wg-dynamic](https://git.zx2c4.com/wg-dynamic/about/docs/idea.md) which
-does handle the IP allocation and rotates the client identifier. So maybe in the 
+The dynamic IP allocation and the lack of forward secrecy for client
+identifiers are being worked on in a separate tool named
+[wg-dynamic](https://git.zx2c4.com/wg-dynamic/about/docs/idea.md) which does
+handle the IP allocation and rotates the client identifier. So maybe in the
 future those will be solved when wg-dynamic becomes more mature.
 
 Right now for us adopting WireGuard would require a lot of development work to