Reflections on WireGuard Design Goals
konstantin at linuxfoundation.org
Fri Aug 10 16:47:17 CEST 2018
On Fri, Aug 10, 2018 at 02:35:14PM +0100, Brian Candler wrote:
>From my point of view, the only thing which makes me uncomfortable
>about wireguard is the lack of any second authentication factor. Your
>private key is embedded in a plaintext file in your device (e.g.
>laptop), not even protected with a passphrase. Anyone who gains access
>to that laptop is able to establish wireguard connections.
I think one way of solving this is teaching the client-side tools to
hook into the TPM. We still grab the key and store it in memory (as
opposed to using TPM's crypto processing directly), but at least this
way it's not lying around on disk somewhere, and it doesn't require
changing anything about the protocol. I am hoping to hit up James
Bottomley about it when I next see him -- he's already written quite a
few tools that use TPM, including teaching GnuPG how to use it. :)
>But I'd feel a lot happier if a second level of authentication were
>required to establish a wireguard connection, if no packets had been
>flowing for more than a configurable amount of time - say, an hour. It
>would give some comfort around lost/stolen devices.
I believe this is orthogonal to the design of the protocol, which is
supposed to behave in a "stateless" fashion and resume transparently
after even prolonged downtimes. We use 2-factor authentication with
OpenVPN, and one of the most annoying aspects about it is the fact that
you have to manually re-auth after each VPN blip. If you don't do it
quickly enough, all your sessions get reset -- most horrible experience
if you are hoping your ssh connection to a server doesn't get severed in
the middle of a yum update.
>Whilst I appreciate that wireguard is symmetrical, a common use case is
>to have remote "clients" with a central "office". I'm thinking about a
>hook whereby the "office" side could request extra authentication when
>required - e.g. if it sees a connection from a wireguard public key
>which has been idle for more than a configurable amount of time, then
>it sends a challenge which requires (e.g.) a Yubikey to complete. I
>appreciate that it's not going to be straightforward, requiring the
>kernel module to talk to userland components at both ends.
I think Wireguard's primary strength is its resilience to network blips
and fast operation. We intend to use it for site-to-site connectivity
across disjointed infrastructure where it will certainly operate much
smoother than OpenVPN or ipsec. For admin-to-site connections we will
continue to use OpenVPN or some combination thereof, until we figure out
a straightforward way of "upgrading" access level of a wireguard
connection. I suspect this is fairly easy with iptables and fwmark, but
I need to test and streamline it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: not available
More information about the WireGuard