
A Mechanised Cryptographic Proof of the WireGuard VPN Protocol - colinprince
https://hal.inria.fr/hal-02100345
======
rahimnathwani
WireGuard is awesome once you have it set up, but I find user management a
little fiddly due to the need to generate a key pair and assign an IP address
for each client.

The last time I set up a WireGuard server, I used this script (with minor
modifications) to create the users:

[https://github.com/adrianmihalko/wg_config](https://github.com/adrianmihalko/wg_config)

But, the _next_ time I set up a WireGuard server, I'll use this web-based
admin UI, which displays a QR code to easily configure a mobile client:

[https://github.com/subspacecloud/subspace](https://github.com/subspacecloud/subspace)

~~~
withzombies
Algo can be used to configure WireGuard also:
[https://github.com/trailofbits/algo](https://github.com/trailofbits/algo)

It automatically handles server provisioning, creating users, and can also
generate QR codes.

------
brohee
From the INRIA team
([https://prosecco.gforge.inria.fr](https://prosecco.gforge.inria.fr)) that
did a lot of work on formal proofs of TLS implementation, leading to a host of
CVE, and whose input was very influential on TLS 1.3.

------
blocke
I setup Wireguard and was pleased with the setup. Unfortunately I tried to use
it over the next week only to quickly realize I should have kept my OpenVPN
install instead.

Outbound port filtering is incredibly common on public and guest wifi networks
and I found three use cases in my first week where OpenVPN on 443/tcp would
have worked fine. The inability to use Wireguard over TCP and bypass most
outbound port filtering by using tcp 443/etal makes it unusable in my daily
life. I can understand why TCP isn't performant but my choice isn't
performance vs non-performant. It's works somewhat vs GFY.

And yes I've seen the udp over tcp forwarding hacks. They don't work on iOS
and some look outright dangerous (hello open proxy).

Hopefully this can be addressed before Wireguard hits 1.0.

~~~
stock_toaster
Have you tried setting up Wireguard to use a different port?

I use port 4500, which is typically used for ipsec nat traversal, and have
found it available/worked on most networks where the default wireguard port
was filtered.

~~~
blocke
I'll give 4500 a whirl to see if it increases the success rate. It's a good
idea. However it's not inconceivable to have sites like cafes that only allow
80/tcp and 443/tcp because that was an option in the UI on their wifi router
for guest networks.

At this point if I was designing a VPN for client devices I'd have a mode that
looked at as close to HTTPS as possible. There is one tool to tunnel over
websocket but this was already sucking up too much of my play time. :)

Cisco AnyConnect, while expensive and bloated, works great as it initially
connects on 443/tcp and then tries to setup UDP. If UDP fails it just sticks
with the TCP connection and "just works".

------
bblipp
I am one of the authors of the paper. Feel free to ask questions about our
work, I'll try to monitor this thread and come back to answer.

~~~
nickpsecurity
Props to your team's great work doing useful analysis on an important
protocol. I appreciate it. :)

I do have some questions about the assurance CryptoVerif provides. I'm a non-
mathematician that does research in high-assurance security that tracks formal
verification results. What I've read indicates problems can kick in at places
like this:

1\. The logic or modelling used isn't proven sound. There's been tons of
analysis into things like set theory or HOL Light. Is CryptoVerif using a
proven logic?

2\. Recent designs favor kernelized models where about every step or
transition can be proven consistent or just not mess up to begin with. Does
CryptoVerif do this or is there a lot of complexity in it?

3\. The solvers might themselves make mistakes. One mitigation was them simply
driving the steps in 2 that were easy to check and/or providing a log of work
for a trusted checker. Any risks on automated part to worry about?

4\. Small, verifiable TCB. HOL Light and Milawa were explicitly designed for
this. Does CryptoVerif have a trusted checker? Are the design and
implementation of above done in a tiny, easy-to-verify fashion? The EasyCrypt
paper's comparisons to CryptoVerif and CertiCrypt made me think it doesn't.

5\. Verification activities on the code itself, source and/or binary, from
static analysis to property-based testing. Empirical evidence suggests these
catch problems proofs sometimes miss, esp due to specification errors. Even
CompCert had a few. Any of this on CryptoVerif's building blocks?

The answers to these questions might be helpful to people interested in
boosting the assurance of this or other tools in the future. After all, the
proofs can only be as strong as the foundations they're built on.

~~~
bblipp
\- CryptoVerif uses a probabilistic process calculus adapted to its use case,
detailed in [1];

\- There is no verified kernel. All algorithms, including an equational prover
for simplification of games, are implemented in ~30k to 40k LOC of OCaml. The
correctness of CryptoVerif’s game transformations has been proved manually
[1]. A formal link between these proofs and the OCaml code is not established;

\- During a proof, after each game transformation, CryptoVerif checks a list
of invariants. This already allowed to find implementation errors in the past.

\- There are regression tests using proofs that have been done before with
CryptoVerif, with both proofs that are supposed to succeed and proofs that are
supposed to fail.

To conclude, CryptoVerif has no high-assurance guarantees on its code like Coq
and others, but is the only tool that is capable to treat complex real-world
protocols.

[1]
[https://prosecco.gforge.inria.fr/personal/bblanche/publicati...](https://prosecco.gforge.inria.fr/personal/bblanche/publications/BlanchetTDSC07.html)

~~~
nickpsecurity
Ok, thanks! Sounds more like the assurance level of running model checkers on
protocol code with user-supplied specs. It can catch lots of problems but no
guarantees on all inputs/paths.

------
henearkr
Note: just append "/en" to the URL to get the English version. Or you can
manually click on the small "fr en" switch on the upper left side of the text
description.

------
Jonnax
What's the current status of WireGuard?

Is it usable?

I remember reading that Cloudfare is implementing it on their VPN product.

~~~
getsimon
Windows client (pre-alpha) has just been released too.
[https://lists.zx2c4.com/pipermail/wireguard/2019-May/004126....](https://lists.zx2c4.com/pipermail/wireguard/2019-May/004126.html)

~~~
jszymborski
I've been waiting for the Windows client to get finished off before switching
to WireGuard.

I've been using SoftEther in the mean time, and man is it flexible. Punches
through NATs with wild abandon, doesn't get blocked since it communicates
through 443 (if you should so config it), is super portable, and offers solid
security and performance as far as I can tell.

