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.

-K

Attachment: signature.asc
Description: PGP signature

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Reply via email to