From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Brian Candler <b.candler@pobox.com>
Cc: wireguard@lists.zx2c4.com
Subject: Re: Reflections on WireGuard Design Goals
Date: Fri, 10 Aug 2018 10:47:17 -0400 [thread overview]
Message-ID: <20180810144717.GA14062@chatter> (raw)
In-Reply-To: <b66a15d1-c4f1-78a5-cf5a-4d2a4ca9ce54@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 2842 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2018-08-10 14:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1318.1533866648.2201.wireguard@lists.zx2c4.com>
2018-08-10 13:35 ` Reflections on WireGuard Design Goals Brian Candler
2018-08-10 14:09 ` Matthias Urlichs
2018-08-10 14:09 ` Kalin KOZHUHAROV
2018-08-10 14:42 ` Eisfunke
2018-08-10 14:47 ` Konstantin Ryabitsev [this message]
2018-08-10 15:03 ` Roman Mamedov
2018-08-10 16:03 ` Brian Candler
2018-08-10 16:38 ` Kalin KOZHUHAROV
2018-08-10 16:40 ` jungle Boogie
2018-08-10 17:12 ` Aaron Jones
2018-08-10 17:25 ` jungle Boogie
2018-08-10 20:15 ` em12345
2018-08-10 23:07 ` Reuben Martin
2018-08-11 19:18 ` Jason A. Donenfeld
2018-08-11 22:52 ` Luiz Angelo Daros de Luca
2018-08-12 0:15 ` Aaron Jones
2018-08-12 0:46 ` Jason A. Donenfeld
2018-08-12 1:07 ` Aaron Jones
2018-08-09 21:52 Jason A. Donenfeld
2018-08-10 15:19 ` nicolas prochazka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180810144717.GA14062@chatter \
--to=konstantin@linuxfoundation.org \
--cc=b.candler@pobox.com \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).