Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
leap_se
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
This is an archived project. Repository and other project resources are read-only.
Show more breadcrumbs
leap
leap_se
Commits
f2d1631a
Unverified
Commit
f2d1631a
authored
4 years ago
by
meskio
Browse files
Options
Downloads
Patches
Plain Diff
On wireguard
parent
28d8a5de
No related branches found
No related tags found
1 merge request
!37
On wireguard
Pipeline
#42746
failed
4 years ago
Stage: production
Changes
2
Pipelines
1
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
pages/about-us/news/2020/wireguard.md
+72
-0
72 additions, 0 deletions
pages/about-us/news/2020/wireguard.md
pages/img/pages/wireguard.png
+0
-0
0 additions, 0 deletions
pages/img/pages/wireguard.png
with
72 additions
and
0 deletions
pages/about-us/news/2020/wireguard.md
0 → 100644
+
72
−
0
View file @
f2d1631a
@title = 'On wireguard'
@author = 'meskio'
@posted_at = '2020-07-01'
@more = true
@preview_image = '/img/pages/wireguard.png'
Our VPN is built on top of
[
OpenVPN
](
https://openvpn.net/
)
, a well tested and
widely used technology that has been around for almost two decades. As most
software with enough history it has grown with a lot of features and code
complexity. This is great as it has everything that we need to provide a stable
service, but at the same time it brings now and then security issues. The
OpenVPN team has been really good on handling them in a timely manner and in
LEAP we've been lucky to have designed our VPN in a way that prevented us from
being affected by most of the ones that has 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 a small code base. This makes it very
fast VPN and is 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 case and 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.
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
)
,
[
socat
](
http://www.dest-unreach.org/socat/
)
or
[
udptunnel
](
http://www1.cs.columbia.edu/~lennox/udptunnel/
)
. All of them sounds
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 connect. 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.
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
(the latest version) if you authenticate the clients using a cert, which we use
to avoid having a list of users, the cert is sent unencrypted. That means that
currently an observer does not even need a compromised server private key to
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 a separated tool named
[
wg-dynamic
](
https://git.zx2c4.com/wg-dynamic/about/docs/idea.md
)
. wg-dynamic
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 will require a lot of development work to
get around those issues and to get a new technology stable enough to be used in
production. We already have our hands full maintianing the existing service and
prefer to priorize our energies to provide a more stable and smooth VPN.
This diff is collapsed.
Click to expand it.
pages/img/pages/wireguard.png
0 → 100644
+
0
−
0
View file @
f2d1631a
34.1 KiB
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment