Re: Reflections on WireGuard Design Goals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/08/18 00:46, Jason A. Donenfeld wrote: > This is in fact true, but I'm not sure we're planning on following > suite with that kind of thing in kernel space for WireGuard... Indeed. :) -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAltviFMACgkQivBzdIir MBIolg//Tbt8zZy/nqtY3njasE6n5OXGs/qSP2GZbJSB4Ieyi1TZfJRumJTNfKSM YLHZmaju+KZO85f6fwj+wqe89swD6WD0mGPKpCwhc+3j403YyT/ggp9uyqSTP78H D9KEIFnX50mtwnj6cWzY3U9H3V0katWRms0P65U90kJF1Fb91EeAplIZnHlIygwa m9+lBB8oJ+dXgkNmjaajI23idYV1qFVw8z9TR22lyXjAWsK0evJ1rcpKtuiIn9FX 3eZ+0QBNF5lCDVyWKl8Y04rattFde3jWs9AAzDPP4nv8GJqo9Jpponzy8jXSFxu5 CwvDShMS3ytWIO+zmSskkcZmh7h00puDhLzVRXneTfE7kbIyT31xQsH4sS2LQ4cY 4W3RoIYY7DnJW1IEaUYa3FAVWjW7XNZUUAU0fNcYJHVmqrPtDJYm692OEv8Hou3+ yn2YjaXaQPXPFqztLrExqDQL2RS4evSx0TRgTBp39ya43MDILM+EG3j04G4ibuyV EeDykMd6KY3h3fVsxhQBE0lryDgS2QHZsr+6ziwFzP8e0Pmy6vU32iNEw1MhEItX 4ffufoanwXO7UKPpcoHCZDOzcxbo7DUDt4EEQpLYSOr4fXqcHfxY6dhT1vetRA0U rnVnX2/tkrDUKJcUI8d7DV1WJqQQUBWdNLzZXWuYcAE08U74U+I= =4Yzj -END PGP SIGNATURE- ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On Sat, Aug 11, 2018, 17:15 Aaron Jones wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 11/08/18 22:52, Luiz Angelo Daros de Luca wrote: > > I see these wireguard extra features just like dhcp is. Nobody > > thinks about implementing dhcp inside kernel or even iproute > > tools. > > The Linux kernel has a (minimal, non-configurable) DHCP client already > (used for rootfs on NFS without an initramfs, among other things). > > CONFIG_IP_PNP_BOOTP=y > This is in fact true, but I'm not sure we're planning on following suite with that kind of thing in kernel space for WireGuard... > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAltvfB4ACgkQivBzdIir > MBLldA//aCK1DHoew8joweZkI2coLZjolMqPActFDTtDkIXAka3guJjh2zVDCxVF > 45AdF1Xv7jhmuDB4emCgH6ANk0vPDAHvs6SBYYZgHvvHdNbBzmM9FqJFk01KHUkl > LhPVCjR9T9EMNifoP5EI1R3YTpoAQbUpaJJ9K12rumdGMelpVU7qg7hW7VkscwAq > WtmN/wuD3w3mZKH+TvtlT409JefvocvE9kA7NUXWOZ9Bxxj3pEJIVTmquE6MS4rm > zHcQ7hY3JR7cPg4Imc0FHuyvbU55R2AnU9+00+dTUISlBT9k2pneIw4EhW0WSHLK > uXXplZfpwV9WSiI/n1dXX1RdRc/42U6LsD4ZLPr6uxoULyeM0ahW7P2+Zq7+yt34 > gEDjwTdLSLQYpLEWhAZ4q6fBLGamZHqXgLXTtioWrIqr5eaScYJcINNjsnAEa8Kz > 3Oo5HOxvJvEMyDz35M+04ugAbjW5LHiqWsOoWfX0A2XfDPt9mnTuiPXrGSLEPWdh > 5OvOsPAmda4/CbJo83cRHqwhsOvoxIJX5+Ewx8giyLZ4lWIGum57wD6n6ZaUVsHZ > 9OXA8f7LZdkxKZ/QSFi7HN9S7SRdkCbJB9E0L96AAVhPGbZuXkGavN5sIOA3fd7Y > CWMCI3Y+x675gtYTpVooR+P1fTWgBAHOHuVFeU8e+LSHwhMallc= > =OY67 > -END PGP SIGNATURE- > ___ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/08/18 22:52, Luiz Angelo Daros de Luca wrote: > I see these wireguard extra features just like dhcp is. Nobody > thinks about implementing dhcp inside kernel or even iproute > tools. The Linux kernel has a (minimal, non-configurable) DHCP client already (used for rootfs on NFS without an initramfs, among other things). CONFIG_IP_PNP_BOOTP=y -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAltvfB4ACgkQivBzdIir MBLldA//aCK1DHoew8joweZkI2coLZjolMqPActFDTtDkIXAka3guJjh2zVDCxVF 45AdF1Xv7jhmuDB4emCgH6ANk0vPDAHvs6SBYYZgHvvHdNbBzmM9FqJFk01KHUkl LhPVCjR9T9EMNifoP5EI1R3YTpoAQbUpaJJ9K12rumdGMelpVU7qg7hW7VkscwAq WtmN/wuD3w3mZKH+TvtlT409JefvocvE9kA7NUXWOZ9Bxxj3pEJIVTmquE6MS4rm zHcQ7hY3JR7cPg4Imc0FHuyvbU55R2AnU9+00+dTUISlBT9k2pneIw4EhW0WSHLK uXXplZfpwV9WSiI/n1dXX1RdRc/42U6LsD4ZLPr6uxoULyeM0ahW7P2+Zq7+yt34 gEDjwTdLSLQYpLEWhAZ4q6fBLGamZHqXgLXTtioWrIqr5eaScYJcINNjsnAEa8Kz 3Oo5HOxvJvEMyDz35M+04ugAbjW5LHiqWsOoWfX0A2XfDPt9mnTuiPXrGSLEPWdh 5OvOsPAmda4/CbJo83cRHqwhsOvoxIJX5+Ewx8giyLZ4lWIGum57wD6n6ZaUVsHZ 9OXA8f7LZdkxKZ/QSFi7HN9S7SRdkCbJB9E0L96AAVhPGbZuXkGavN5sIOA3fd7Y CWMCI3Y+x675gtYTpVooR+P1fTWgBAHOHuVFeU8e+LSHwhMallc= =OY67 -END PGP SIGNATURE- ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
> I think that given the WireGuard building block, it's certainly > possible to build a 2FA framework around it. > I see these wireguard extra features just like dhcp is. Nobody thinks about implementing dhcp inside kernel or even iproute tools. +1 for 2FA and +1 for a service that share peer info, allowing a mesh vpn > -- Luiz Angelo Daros de Luca luizl...@gmail.com ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On Fri, Aug 10, 2018 at 6:35 AM Brian Candler wrote: > But I'd feel a lot happier if a second level of authentication were > required to establish a wireguard connection I think that given the WireGuard building block, it's certainly possible to build a 2FA framework around it. And I do generally like 2FA and short-lived credentials and such. Probably after getting the implementations buttoned up -- kernel mainline, windows, etc -- I'll turn a bit of attention to expanding tooling and full packages around the simple wg0 interface. Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On Fri, Aug 10, 2018, 3:16 PM em12345 wrote: > Hi, > > > 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. > > Most VPN authentications are just authorizing the machine and not the > user sitting in front of that machine. > > > Anyone who gains access to that > > laptop is able to establish wireguard connections. > > > > Of course, it can be argued that the laptop holds other information > > which is more valuable that the wireguard key, therefore you should > > concentrate on properly securing the laptop itself (*). Furthermore, > > No matter how much keys, passwords or tokens have to be entered by the > user sitting in front of that machine, any other user already on that > machine, will gain sooner or later access to the tunnel. This user or > attacker doesn't even need to see/know wireguard's private key nor does > the attacker need root access. Think of a second user logged in on that > machine. > > It is definitely a bad idea to assume that the tunnel traffic of one > "client" (in terms of wg's client key pair) comes from a specific user. > Which also means that even multi factor VPN authentication still require > all services inside the tunnel to ask for user authentication. > It should me noted that it is possible to isolate the VPN access to a specific user if you assign login sessions to isolated network namespaces and place the wireguard interface within the user's namespace. -Reuben > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
Hello together, > In the absence of that, it would be nice if the private key which is > stored on the laptop were encrypted with a passphrase. Simplest option > may be to extend wg-quick so that the entire config file can be > pgp-encrypted. one can already do that via the wg-quick PostUp hook, check out the Arch Linux wiki: https://wiki.archlinux.org/index.php/ WireGuard#Store_private_keys_in_encrypted_form The example is using pass, switching it for direct GPG (or keepassxc or anything, really) should be easily possible. Considering that possibility, I don't think adding GnuPG directly into Wireguard would be a good idea. It would just add complexity for little to no benefit. Greetings, NIcolas Lenz ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
Hi, > 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. Most VPN authentications are just authorizing the machine and not the user sitting in front of that machine. > Anyone who gains access to that > laptop is able to establish wireguard connections. > > Of course, it can be argued that the laptop holds other information > which is more valuable that the wireguard key, therefore you should > concentrate on properly securing the laptop itself (*). Furthermore, No matter how much keys, passwords or tokens have to be entered by the user sitting in front of that machine, any other user already on that machine, will gain sooner or later access to the tunnel. This user or attacker doesn't even need to see/know wireguard's private key nor does the attacker need root access. Think of a second user logged in on that machine. It is definitely a bad idea to assume that the tunnel traffic of one "client" (in terms of wg's client key pair) comes from a specific user. Which also means that even multi factor VPN authentication still require all services inside the tunnel to ask for user authentication. Emmanuel ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
> > On 10/08/18 16:40, jungle Boogie wrote: >> If someone already has my ssh key, I'd revoke it - regardless if >> they had the password or not. Same with the WG key - shutdown the >> tunnel, remove the affected peer and start it back up. > > No need to interrupt the tunnel. > > # wg set peer remove > Dang, that's cool! That's for the info. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/08/18 16:40, jungle Boogie wrote: > If someone already has my ssh key, I'd revoke it - regardless if > they had the password or not. Same with the WG key - shutdown the > tunnel, remove the affected peer and start it back up. No need to interrupt the tunnel. # wg set peer remove -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAlttx3oACgkQivBzdIir MBJTWw//dL9Te/8nfr18EQQEmWXRqgS7A6QrXh5lrAjTlHAHuzbfM2sp+mt5ML50 fmEHlsVHZqM4rG4l1+KiSrUb6n7hlzoCO2bwh36U/tdysXgf20vM9XN4vyhvWMbN eOB6CNHfso02uMzx4TCAaK2ZcWnsqh1LvXceVwMQdJ6+E2FDpu637TYEiWJyIDPv u/q5Qq+qZspFiqDTpAJ/scdLq+4AxnzeELs/OblfRYbvE+Hkc9VsunxXJImXvcKx cN1NldPxwR+a4fWTvKgIqVReIKEggDl4OzYZk+wipFLRwQWASYW3aYQ+UeQEaUHa TQqkfZ6PqvivKLPC+Ih3DVHYd4Xa4t+zC/gVtQYgAauhqcqtpH1Y0ZISohIR9x/t 2GMxOZPg7Q6x05qf0bKdWPgdH+lcENW1HYEhj/cWrKaCAoKgKOnGsfgUNEdvRXMb i/RiLnJ5NH07sg4C/QRdVOXxx/TwBoEZPvgXUsxteadBc77LLOR4ERNVZ4zQrvhv JhhLeckOL9dmywPuvvO4sc/cOZCvb2kaYSDD1Tn4iJaqWZwWdA8HNnGyBnl14mMF 9ER5qzSA0L9QRDXhyBkv1+ekDmshBnpyj6PN7kBJ5cl9WVZXLjIsUWcte9YXfbIM MqwqhoGBdF0n5T41OP0zt4vT1DWLF9pGsOiUUq7GahpIXp1mPMo= =T+rR -END PGP SIGNATURE- ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On 10 August 2018 at 09:03, Brian Candler wrote: > On 10/08/2018 16:03, Roman Mamedov wrote: > > 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. > > Couldn't you just encrypt your home directory? Or even the root FS entirely. > Either of those should be a must on a portable device storing valuable > information. > > But by analogy, would you say that SSH keys and PGP keys don't need > protection by a passphrase? > If someone already has my ssh key, I'd revoke it - regardless if they had the password or not. Same with the WG key - shutdown the tunnel, remove the affected peer and start it back up. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On Fri, 10 Aug 2018, 19:04 Brian Candler, wrote: > On 10/08/2018 16:03, Roman Mamedov wrote: > > 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. > > Couldn't you just encrypt your home directory? Or even the root FS entirely. > Either of those should be a must on a portable device storing valuable > information. > > But by analogy, would you say that SSH keys and PGP keys don't need > protection by a passphrase? > Yes, I will say so. I (almost) never use it, it is either too unsecure yet cumbersome, so I use separate devices (nFA), encrypted FS, etc. where needed. Or nothing at all. Kalin. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On 10/08/2018 16:03, Roman Mamedov wrote: 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. Couldn't you just encrypt your home directory? Or even the root FS entirely. Either of those should be a must on a portable device storing valuable information. But by analogy, would you say that SSH keys and PGP keys don't need protection by a passphrase? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
hello,
just to say you, as a simple end user
we are using wireguard since one year for our product,
we have 10K tunnels deployed ,
wireguard is perfect for us, very simple, we can develop our specific
code on top of if ( key management , )
so +1 for jason vision
thanks for this piece of code
Regards,
Nicolas
Le jeu. 9 août 2018 à 23:52, Jason A. Donenfeld a écrit :
>
> Hey list,
>
> For whatever reason, in the last several weeks, WireGuard been receiving a
> considerable amount of attention, and with that comes various parties
> interested in the project moving in this direction or in that direction. And
> more generally, over the last year or so, we've seen a decent amount of
> interest from different folks wanting to do different things with the project
> and with the protocol. This inevitably leads to the question: what do we
> actually want WireGuard to be, as a project, as a protocol, as a set of
> implementations, as a design methodology, and so forth? I've had a pretty
> clear idea about that, but I don't think I've ever tried to communicate
> aspects of it in this context, so I thought here I'd highlight two important
> design goals that motivate us.
>
> Firstly, WireGuard intends on continuing to have a minimal core, without a lot
> of options and wild features and support for weird networking paradigms. Sure,
> we want the core to be sufficiently flexible that you can build interesting
> and complex things on top of it, but we don't want WireGuard itself to be
> complicated. We enjoy our small understandable configuration files, an
> interface that appears to be mostly stateless, and general ease of use. Even
> from a cryptography and implementation perspective, the protocol is designed
> to be implementable using simple algorithms and coding techniques.
>
> With that kind of minimalism naturally comes the temptation to add things.
> Simply from the perspective of an interested engineer, it's appealing to
> extend and hack on small manageable codebases and projects, since adding a
> single feature here or there just isn't that hard. And after all, if you're
> *just* adding *one* feature, it's only one, and that's not so bad, right? And
> what about one more? This kind of temptation applies equally to features
> inside implementations as it does to features inside the protocol. And I think
> this temptation is a little bit dangerous, both because it's an obvious
> slippery slope to bloat ("just one more feature can't hurt, right guys?"), and
> because while individual features or protocol enhancements might be well
> thought-out, it's often hard to think through them in the context of a fuller
> system.
>
> Secondly, WireGuard is engineered slowly and carefully. It is a conservative
> project. Programming is fun, and so I understand the appeal to, "move fast and
> break things," or to ship new code hastily. Personally I've written plenty of
> such codebases, and that's usually fun and exciting. Except WireGuard is
> deeply security-oriented. Of course there will inevitably be scary bugs we
> weren't able to prevent, but we're moving slow and carefully to try to
> mitigate those to the fullest extent we can. We want each of the
> implementations released by the WireGuard project to be secure, high assurance
> software.
>
> This means that although you can probably get something mostly "working" in a
> fairly short amount of time (an initial version of WireGuard took me
> essentially a weekend), we're trying very hard not to throw junk over the
> fence. Rather, we're doing pretty regular code reviews and have received some
> great feedback from some scary-talented security researchers, and we expect
> for this to continue. But indeed not all programmers share this perspective –
> for a wide variety of motivations, both benign and opportunistic – and so we
> definitely will (and have, in fact, already) see folks making things related
> to WireGuard who don't share this type of methodology.
>
> Now I don't think these two motivating principles are particularly unique or
> innovative. Other security-focused projects, like OpenBSD for example, seem to
> be made of a somewhat similar mold. But these also certainly are not the
> _norm_ for most projects out there. And as WireGuard accelerates in usage, I
> expect we'll be facing this from a few angles:
>
> - Attempts at commercialization: There are many businesses who want to embrace
> WireGuard and extend it in some particular direction or another, in order to
> build products or sell services or the usual array of business
> opportunities. Engineers working in these contexts often times are tempted
> to extend minimal things in grotesque ways, and to push them to market with
> deadlines unfavorable to high assurance methodologies. It's naturally and
> understandably in the interest of businesses to attempt to steer the
> WireGuard project in directions aligned with their goals, or even directly
> hire WireGuard developers away
Re: Reflections on WireGuard Design Goals
On Fri, 10 Aug 2018 14:35:14 +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. > > Of course, it can be argued that the laptop holds other information > which is more valuable that the wireguard key, therefore you should > concentrate on properly securing the laptop itself (*). Furthermore, to > be able to talk to the wireguard kernel module you're already root, and > therefore have all sorts of malicious options available to you. etc etc > > 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. Couldn't you just encrypt your home directory? Or even the root FS entirely. Either of those should be a must on a portable device storing valuable information. -- With respect, Roman ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
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 signature.asc Description: PGP signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
On 10.08.2018 15:35, Brian Candler wrote: > 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. It's reasonably easy to add that as a service on top of Wireguard, once you have an authenticated connection. The office can easily talk to an app on the mobile device when it notices a re-awakened stale connection (triggered by a firewall logging rule, for instance), exchange whatever crypto it requires, and only then allow packets other than those required for authenticating to flow through the interface (another simple firewall rule change). Adding a feature like this to the WG kernel itself would not be any more secure (and indeed add a significant amount of complexity which may exhibit exploitable bugs). It would also unnecessarily enshrine a particular 2FA scheme into wireguard. -- -- Matthias Urlichs signature.asc Description: OpenPGP digital signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
Please excuse my brevity, phone typing here... On Fri, 10 Aug 2018, 16:36 Brian Candler, wrote: > Thanks for explaining the project background, and your very sensible > goals of simplicity and robustness. And thanks for releasing this > excellent piece of software. > > 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. Not always. You can generate it on the fly (say 1st boot, no config file), distribute it and be done. Or you can choose to protect it (e.g. pgp), may be even store it in a HSM. Or throw it (keep in RAM) and regenerate, if needed. Anyone who gains access > to that laptop is able to establish wireguard connections. > > Of course, it can be argued that the laptop holds other information > which is more valuable that the wireguard key, therefore you should > concentrate on properly securing the laptop itself (*). Furthermore, to > be able to talk to the wireguard kernel module you're already root, and > therefore have all sorts of malicious options available to you. etc etc > > 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. > And what do we do (count or not) keepalive traffic? 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. > That is way overcomplicated... And how did you solve your key distribution in such scenario BTW? (hint: the functionality you request is part of key handling, i.e. NOT part of wg, AFAIK). The office end can expire any user key and request sidechannel (additional, 2FA or more) authentication via the established link. Who says wg tunnel should be to the network core? Use a standard firewall, plug a RADIUS even, or script your way on top of wg. Feel free to provide a clean interface to wg and documentation and people who want that functionality will use the code. Is there anything (e.g. design-level) that prevents that? Or functionality that is lacking at the core? > > In the absence of that, it would be nice if the private key which is > stored on the laptop were encrypted with a passphrase. Simplest option > may be to extend wg-quick so that the entire config file can be > pgp-encrypted. > Now that also is not 2FA, and yes it should be a few lines of scripting. Kalin. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Reflections on WireGuard Design Goals
For whatever reason, in the last several weeks, WireGuard been receiving a considerable amount of attention, and with that comes various parties interested in the project moving in this direction or in that direction. And more generally, over the last year or so, we've seen a decent amount of interest from different folks wanting to do different things with the project and with the protocol. This inevitably leads to the question: what do we actually want WireGuard to be, as a project, as a protocol, as a set of implementations, as a design methodology, and so forth? I've had a pretty clear idea about that, but I don't think I've ever tried to communicate aspects of it in this context, so I thought here I'd highlight two important design goals that motivate us. Thanks for explaining the project background, and your very sensible goals of simplicity and robustness. And thanks for releasing this excellent piece of software. 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. Of course, it can be argued that the laptop holds other information which is more valuable that the wireguard key, therefore you should concentrate on properly securing the laptop itself (*). Furthermore, to be able to talk to the wireguard kernel module you're already root, and therefore have all sorts of malicious options available to you. etc etc 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. 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. In the absence of that, it would be nice if the private key which is stored on the laptop were encrypted with a passphrase. Simplest option may be to extend wg-quick so that the entire config file can be pgp-encrypted. Regards, Brian. (*) You could make a similar argument for ssh keys or pgp keys, saying there's no need to protect them with a passphrase if the host they are stored on is properly secured. I think many people would disagree. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Reflections on WireGuard Design Goals
Hey list,
For whatever reason, in the last several weeks, WireGuard been receiving a
considerable amount of attention, and with that comes various parties
interested in the project moving in this direction or in that direction. And
more generally, over the last year or so, we've seen a decent amount of
interest from different folks wanting to do different things with the project
and with the protocol. This inevitably leads to the question: what do we
actually want WireGuard to be, as a project, as a protocol, as a set of
implementations, as a design methodology, and so forth? I've had a pretty
clear idea about that, but I don't think I've ever tried to communicate
aspects of it in this context, so I thought here I'd highlight two important
design goals that motivate us.
Firstly, WireGuard intends on continuing to have a minimal core, without a lot
of options and wild features and support for weird networking paradigms. Sure,
we want the core to be sufficiently flexible that you can build interesting
and complex things on top of it, but we don't want WireGuard itself to be
complicated. We enjoy our small understandable configuration files, an
interface that appears to be mostly stateless, and general ease of use. Even
from a cryptography and implementation perspective, the protocol is designed
to be implementable using simple algorithms and coding techniques.
With that kind of minimalism naturally comes the temptation to add things.
Simply from the perspective of an interested engineer, it's appealing to
extend and hack on small manageable codebases and projects, since adding a
single feature here or there just isn't that hard. And after all, if you're
*just* adding *one* feature, it's only one, and that's not so bad, right? And
what about one more? This kind of temptation applies equally to features
inside implementations as it does to features inside the protocol. And I think
this temptation is a little bit dangerous, both because it's an obvious
slippery slope to bloat ("just one more feature can't hurt, right guys?"), and
because while individual features or protocol enhancements might be well
thought-out, it's often hard to think through them in the context of a fuller
system.
Secondly, WireGuard is engineered slowly and carefully. It is a conservative
project. Programming is fun, and so I understand the appeal to, "move fast and
break things," or to ship new code hastily. Personally I've written plenty of
such codebases, and that's usually fun and exciting. Except WireGuard is
deeply security-oriented. Of course there will inevitably be scary bugs we
weren't able to prevent, but we're moving slow and carefully to try to
mitigate those to the fullest extent we can. We want each of the
implementations released by the WireGuard project to be secure, high assurance
software.
This means that although you can probably get something mostly "working" in a
fairly short amount of time (an initial version of WireGuard took me
essentially a weekend), we're trying very hard not to throw junk over the
fence. Rather, we're doing pretty regular code reviews and have received some
great feedback from some scary-talented security researchers, and we expect
for this to continue. But indeed not all programmers share this perspective –
for a wide variety of motivations, both benign and opportunistic – and so we
definitely will (and have, in fact, already) see folks making things related
to WireGuard who don't share this type of methodology.
Now I don't think these two motivating principles are particularly unique or
innovative. Other security-focused projects, like OpenBSD for example, seem to
be made of a somewhat similar mold. But these also certainly are not the
_norm_ for most projects out there. And as WireGuard accelerates in usage, I
expect we'll be facing this from a few angles:
- Attempts at commercialization: There are many businesses who want to embrace
WireGuard and extend it in some particular direction or another, in order to
build products or sell services or the usual array of business
opportunities. Engineers working in these contexts often times are tempted
to extend minimal things in grotesque ways, and to push them to market with
deadlines unfavorable to high assurance methodologies. It's naturally and
understandably in the interest of businesses to attempt to steer the
WireGuard project in directions aligned with their goals, or even directly
hire WireGuard developers away from an independent perspective working on
the open source project. This is pretty commonplace with open source
projects, and while sometimes everyone's interests align perfectly, it's
easy to loose sight of the broader project goal; in particular, the goal of
minimalism in particular is easy to leave by the wayside.
- Folks who want their own corner of the Internet: We've already seen this
with a project, and as things accelerate, we'll probably also see it with
others. It's fun to run a
