Re: Tunsafe Windows client for wireguard (not opensource yet they say
Hi Ludvig, On 6 March 2018 at 02:44, Ludvig Strigeus wrote: > Jason A. Donenfeld wrote: >> This isn't the source code of tunsafe. This is the source code of the > >> OpenVPN Windows tuntap kernel driver, which has been hacked up in > various >> ways for tunsafe. That's a super scary driver, by the way. > > Incorrect. The driver files are not modified at all. They still > carry OpenVPN's codesigning signature. You can see this on the > driver install prompt: > https://tunsafe.com/img/quickstart-driver-confirm.png > > I agree that the driver is scary, I think I even found some > potential OOB memory accesses in it from a quick glance. However, > this is the best driver the community has at this point in time, > and even your own userspace implementations of WG use it. I'd > be happy to improve it but then I need an expensive driver > codesigning certificate in order to load it into the kernel. Please report any issues you find in the tap-windows driver to secur...@openvpn.net, so those can be fixed and many more people can profit from your work. In the same train of thought: you don't need a code signing certificate to improve the driver, you are more than welcome to work with the openvpn community to improve it (I expect, I don't actually work on tap-windows myself). Just send your patches to openvpn-de...@lists.sourceforge.net, or discuss your plans beforehand on the list if you want confirmation that your plans are okay with the community. Then wait for the next OpenVPN release to get your signed binary :) -Steffan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Tunsafe Windows client for wireguard (not opensource yet they say
On Tue, Mar 6, 2018 at 2:44 AM, Ludvig Strigeus wrote: > The driver files are not modified at all. They still > carry OpenVPN's codesigning signature. Both good and bad to hear. That's a really really flaky driver, and it _does_ need to be hacked to pieces, removing tons of things, in order for it to be real software someone would want to run. On the other hand, at least you get code signing for free. > First of all could you change tone a little bit, personal attacks and > rudeness do not have a place in those discussions unless you actually > back them up with facts. There are no personal attacks. I don't know much about you, beyond uTorrent and adware. Rather, my comments are in relation to your software -- which doesn't implement the protocol correctly and has security issues. (Your stripped binaries really wasted way too much time, by the way.) It's not safe for users to use. I've got a duty to such users to inform them when these types of security and interoperability issues crop up. > but your attitude appears to be that everything that > is not open source, and hosted under the WireGuard brand/webpage, is > community-unfriendly and nasty. Is that what you mean by community > unfriendly? No I think the notion is a bit different than that. This community here looks very closely at design decisions and implementations, making sure we deliver secure software of high quality. Part of that means working together and doing extensive code reviews and sharing source code. Another part of that is keeping things unified as one single project. From the beginning you've seemed interested in bifurcation, and releasing hastily written software with little review quickly. > probably want it under my own name, > on my own website, where I'm free to develop the project in any > direction I want Sounds to be like an interoperability and compatibility disaster in the making, NIH gone bad. > I don't want to spend weeks or months building a client for it to end > up on some semi-hidden place on wireguard.com just because you > prefer Rust or Go, where my contribution may get diminished into > nothing at all. Actually that's not the case at all. On a personal note, I've spent decades writing C++, and I'm surprisingly fond of it, despite its warts. I used to keep Stroustrup's book on the back of the toilet for casual perusing. We have a Rust and a Go implementation because those are what's been contributed by volunteers, and have the nice aspect of being somewhat "safer" to write code in, especially Rust. Aside from your flamebait email here, I (and other developers working on WireGuard) still would be happy to work with you on the codebase to ensure that it's written securely and compatibly, doing regular releases as WireGuard software. But indeed that would mean working with the community and doing things under one roof, not running off and shipping bad bits. > How would you deal with Microsoft if they wanted to add a closed > source implementation of WireGuard in Windows. Would they also > be considered a community-unfriendly proprietary author with a > clear agenda of nastiness? I'm pretty confident Microsoft would pick a reasonable strategy for working with us here and releasing code responsibility. It's true they have that classic history of "embrace, extend, extinguish" (is the new CEO different? maybe?), but knowing some people working on their security teams and crypto teams who would likely be implementing this kind of thing, maybe this wouldn't happen? Or that's being too optimistic? I oscillate between thinking recent github-friendly and linuxsubsystem-writing Microsoft has really changed itself since the 2000s, and thinking this is just naivete on my part. So, who knows what they'd do. One can dream I suppose. > The only accepted > implementation would be that one from yourself? No companies > would be allowed to implement it or take part in discussions? > This is not how Internet protocols typically work. Actually no. There are several people working on several implementations. This list here has extensive discussion about different features, and the design of the protocol has, in extremely large part, been driven by this mailing list. We're a quite open community. > to security. I share this view, and will address it eventually, > in some way. Either just the wireguard protocol layer or the > whole UI too. That's great to hear. I look forward to you open sourcing your project, and we can get to work in earnest on it once this happens. > I'm not interested in being a slave in a dictatorship. That's a pretty offensive and outrageous way of describing any of this. We're an open source project of volunteers. Lots of people are doing their invaluable part and contributing invaluable time. At least two of us are doing this more or less full-time, because we want to. Others are doing this between jobs or between classes or between military deployments. We're all volunteers, working to do this t
Re: Tunsafe Windows client for wireguard (not opensource yet they say
Jason A. Donenfeld wrote: > Please stay away from this software, and generally be wary of > closed-source WireGuard implementations trying to fill the void.* This **> one was written by a community-unfriendly proprietary author*, and > we've got little way of ensuring protocol compliance or basic > security. *Especially from my discussions from him, it's clear what **> he's up to, and this seems like some nastiness.* Should I spend my time > reverse engineering this software and discovering zero-days? Probably > not a good use of my time, despite my usual love of this sort of thing. First of all could you change tone a little bit, personal attacks and rudeness do not have a place in those discussions unless you actually back them up with facts. Never once during our IRC chat did I say something negative about you, instead I wrote several times that WireGuard was fanastic and you're an inspiring person. I'd be happy to share IRC logs of our brief communication with this list to prove my point, but your attitude appears to be that everything that is not open source, and hosted under the WireGuard brand/webpage, is community-unfriendly and nasty. Is that what you mean by community unfriendly? I said that if I release TunSafe I probably want it under my own name, on my own website, where I'm free to develop the project in any direction I want, without pressure to release it as open source. I don't want to spend weeks or months building a client for it to end up on some semi-hidden place on wireguard.com just because you prefer Rust or Go, where my contribution may get diminished into nothing at all. How would you deal with Microsoft if they wanted to add a closed source implementation of WireGuard in Windows. Would they also be considered a community-unfriendly proprietary author with a clear agenda of nastiness? Is this how you envision how things would work should WireGuard become a future RFC / Internet Standard? The only accepted implementation would be that one from yourself? No companies would be allowed to implement it or take part in discussions? This is not how Internet protocols typically work. Given these constraints, I'm happy to participate in whatever protocol discussions or community related questions that I'm in the capacity to answer or contribute to. I totally understand your point about open source applications being easier to audit, especially important when it's related to security. I share this view, and will address it eventually, in some way. Either just the wireguard protocol layer or the whole UI too. Though, your behavior this past day has confirmed even more that I'm not interested in being a slave in a dictatorship. You've ignored my attempts at communications for 2 weeks. You ban me from #wireguard IRC even though I haven't talked there for weeks, but just because I'm in there and not being as much of a die-hard open-source evangelist as you are. Jason A. Donenfeld wrote: > This isn't the source code of tunsafe. This is the source code of the > OpenVPN Windows tuntap kernel driver, *which has been hacked up in **> various ways for tunsafe*. That's a super scary driver, by the way. Incorrect. The driver files are not modified at all. They still carry OpenVPN's codesigning signature. You can see this on the driver install prompt: https://tunsafe.com/img/quickstart-driver-confirm.png I agree that the driver is scary, I think I even found some potential OOB memory accesses in it from a quick glance. However, this is the best driver the community has at this point in time, and even your own userspace implementations of WG use it. I'd be happy to improve it but then I need an expensive driver codesigning certificate in order to load it into the kernel. /Ludde ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Tunsafe Windows client for wireguard (not opensource yet they say
On Mon, Mar 5, 2018 at 12:19 PM, David Woodhouse wrote: > I wasn't sure whether to suggest this before, but adding Wireguard > support to OpenConnect ought to be fairly easy. We already support > three VPN protocols, so we have a *relatively* sane distinction between > the protocol-specific parts, and all the OS-specific tun device > handling and other bits that would just be gratuitous wheel-reinvention > for you. > > It basically gives you support for Windows, Solaris, OSX, Android and > various BSDs for nothing. With NetworkManager support. > > For a client that *isn't* purely wrapping the kernel implementation, it > probably makes sense rather starting from scratch. If anyone's > interested in working on it, I'd be happy to give some pointers. > > (I've also looked in the past at adding kernel support too, for DTLS > acceleration; I may take a look at that again.) That sounds pretty excellent. I'll add that the project TODO list and maybe we'll get an interested contributor or a GSoC student for it. By the way, how would you feel about doing this via the existing Go and Rust implementations? If I can jerry rig it into the build system, would you be interested? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Tunsafe Windows client for wireguard (not opensource yet they say
On Mon, Mar 5, 2018 at 12:29 PM, Sebastian Gottschall wrote: > it isnt closed source. the sourcecode is provided as far as i have seen and > licensed under GPL > but correct me if i'm wrong > https://tunsafe.com/downloads/TunSafe-TAP-9.21.2-sources.zip This isn't the source code of tunsafe. This is the source code of the OpenVPN Windows tuntap kernel driver, which has been hacked up in various ways for tunsafe. That's a super scary driver, by the way. The actual source code of tunsafe is closed source. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Tunsafe Windows client for wireguard (not opensource yet they say
nevermind. its just the tap source Am 05.03.2018 um 10:19 schrieb Jason A. Donenfeld: Hi Henrique, Thanks for posting this. Please stay away from this software, and generally be wary of closed-source WireGuard implementations trying to fill the void. This one was written by a community-unfriendly proprietary author, and we've got little way of ensuring protocol compliance or basic security. Especially from my discussions from him, it's clear what he's up to, and this seems like some nastiness. Should I spend my time reverse engineering this software and discovering zero-days? Probably not a good use of my time, despite my usual love of this sort of thing. One aspect of the WireGuard project is that we're taking development very carefully and slowly, not jumping to premature releases, and really studying every bit of what we produce in order to ship the least-vulnerable and most-correct code we possibly can. We're still shipping code -- it's not an approach that results in a complete standstill -- but it does mean that in these intervening periods, there will be propheteers and cowboys coming out of the woodwork to fill the void. It's quite easy to make a tiny tunneling protocol that's reasonably fast and does a few things; if you look on Github there are hundreds. It's quite another thing to write robust and secure software intend to last for a long time. That's what we're working on here. Fortunately we have two very nice projects that are rapidly approaching maturity: one in Go and one in Rust. I fully welcome future OSS authors into the project. When I'm back from visiting family at the beginning of April, I think we'll be in a good place to have a few first releases. I'll also do what I can to see that people aren't peddling junk and calling it wireguard, so as to reduce user confusion, but this of course isn't a very easy endeavor. I'm open to suggestions on how to approach this. Regards, Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Tunsafe Windows client for wireguard (not opensource yet they say
it isnt closed source. the sourcecode is provided as far as i have seen and licensed under GPL but correct me if i'm wrong https://tunsafe.com/downloads/TunSafe-TAP-9.21.2-sources.zip Am 05.03.2018 um 10:19 schrieb Jason A. Donenfeld: Hi Henrique, Thanks for posting this. Please stay away from this software, and generally be wary of closed-source WireGuard implementations trying to fill the void. This one was written by a community-unfriendly proprietary author, and we've got little way of ensuring protocol compliance or basic security. Especially from my discussions from him, it's clear what he's up to, and this seems like some nastiness. Should I spend my time reverse engineering this software and discovering zero-days? Probably not a good use of my time, despite my usual love of this sort of thing. One aspect of the WireGuard project is that we're taking development very carefully and slowly, not jumping to premature releases, and really studying every bit of what we produce in order to ship the least-vulnerable and most-correct code we possibly can. We're still shipping code -- it's not an approach that results in a complete standstill -- but it does mean that in these intervening periods, there will be propheteers and cowboys coming out of the woodwork to fill the void. It's quite easy to make a tiny tunneling protocol that's reasonably fast and does a few things; if you look on Github there are hundreds. It's quite another thing to write robust and secure software intend to last for a long time. That's what we're working on here. Fortunately we have two very nice projects that are rapidly approaching maturity: one in Go and one in Rust. I fully welcome future OSS authors into the project. When I'm back from visiting family at the beginning of April, I think we'll be in a good place to have a few first releases. I'll also do what I can to see that people aren't peddling junk and calling it wireguard, so as to reduce user confusion, but this of course isn't a very easy endeavor. I'm open to suggestions on how to approach this. Regards, Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Tunsafe Windows client for wireguard (not opensource yet they say
google chrome warns if you try to download tunsafe. its potentially unsafe. :-) Am 05.03.2018 um 12:19 schrieb David Woodhouse: On Mon, 2018-03-05 at 10:19 +0100, Jason A. Donenfeld wrote: One aspect of the WireGuard project is that we're taking development very carefully and slowly, not jumping to premature releases, and really studying every bit of what we produce in order to ship the least-vulnerable and most-correct code we possibly can. We're still shipping code -- it's not an approach that results in a complete standstill -- but it does mean that in these intervening periods, there will be propheteers and cowboys coming out of the woodwork to fill the void. I wasn't sure whether to suggest this before, but adding Wireguard support to OpenConnect ought to be fairly easy. We already support three VPN protocols, so we have a *relatively* sane distinction between the protocol-specific parts, and all the OS-specific tun device handling and other bits that would just be gratuitous wheel-reinvention for you. It basically gives you support for Windows, Solaris, OSX, Android and various BSDs for nothing. With NetworkManager support. For a client that *isn't* purely wrapping the kernel implementation, it probably makes sense rather starting from scratch. If anyone's interested in working on it, I'd be happy to give some pointers. (I've also looked in the past at adding kernel support too, for DTLS acceleration; I may take a look at that again.) ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Tunsafe Windows client for wireguard (not opensource yet they say
On Mon, 2018-03-05 at 10:19 +0100, Jason A. Donenfeld wrote: > One aspect of the WireGuard project is that we're taking development > very carefully and slowly, not jumping to premature releases, and > really studying every bit of what we produce in order to ship the > least-vulnerable and most-correct code we possibly can. We're still > shipping code -- it's not an approach that results in a complete > standstill -- but it does mean that in these intervening periods, > there will be propheteers and cowboys coming out of the woodwork to > fill the void. I wasn't sure whether to suggest this before, but adding Wireguard support to OpenConnect ought to be fairly easy. We already support three VPN protocols, so we have a *relatively* sane distinction between the protocol-specific parts, and all the OS-specific tun device handling and other bits that would just be gratuitous wheel-reinvention for you. It basically gives you support for Windows, Solaris, OSX, Android and various BSDs for nothing. With NetworkManager support. For a client that *isn't* purely wrapping the kernel implementation, it probably makes sense rather starting from scratch. If anyone's interested in working on it, I'd be happy to give some pointers. (I've also looked in the past at adding kernel support too, for DTLS acceleration; I may take a look at that again.) smime.p7s Description: S/MIME cryptographic signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Tunsafe Windows client for wireguard (not opensource yet they say
Just post to alert you:) don’t want to install:) Sent from my iPhone > On 5 Mar 2018, at 09:19, Jason A. Donenfeld wrote: > > Hi Henrique, > > Thanks for posting this. > > Please stay away from this software, and generally be wary of > closed-source WireGuard implementations trying to fill the void. This > one was written by a community-unfriendly proprietary author, and > we've got little way of ensuring protocol compliance or basic > security. Especially from my discussions from him, it's clear what > he's up to, and this seems like some nastiness. Should I spend my time > reverse engineering this software and discovering zero-days? Probably > not a good use of my time, despite my usual love of this sort of > thing. > > One aspect of the WireGuard project is that we're taking development > very carefully and slowly, not jumping to premature releases, and > really studying every bit of what we produce in order to ship the > least-vulnerable and most-correct code we possibly can. We're still > shipping code -- it's not an approach that results in a complete > standstill -- but it does mean that in these intervening periods, > there will be propheteers and cowboys coming out of the woodwork to > fill the void. > > It's quite easy to make a tiny tunneling protocol that's reasonably > fast and does a few things; if you look on Github there are hundreds. > It's quite another thing to write robust and secure software intend to > last for a long time. That's what we're working on here. > > Fortunately we have two very nice projects that are rapidly > approaching maturity: one in Go and one in Rust. I fully welcome > future OSS authors into the project. When I'm back from visiting > family at the beginning of April, I think we'll be in a good place to > have a few first releases. > > I'll also do what I can to see that people aren't peddling junk and > calling it wireguard, so as to reduce user confusion, but this of > course isn't a very easy endeavor. I'm open to suggestions on how to > approach this. > > Regards, > Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Tunsafe Windows client for wireguard (not opensource yet they say
Hi Henrique, Thanks for posting this. Please stay away from this software, and generally be wary of closed-source WireGuard implementations trying to fill the void. This one was written by a community-unfriendly proprietary author, and we've got little way of ensuring protocol compliance or basic security. Especially from my discussions from him, it's clear what he's up to, and this seems like some nastiness. Should I spend my time reverse engineering this software and discovering zero-days? Probably not a good use of my time, despite my usual love of this sort of thing. One aspect of the WireGuard project is that we're taking development very carefully and slowly, not jumping to premature releases, and really studying every bit of what we produce in order to ship the least-vulnerable and most-correct code we possibly can. We're still shipping code -- it's not an approach that results in a complete standstill -- but it does mean that in these intervening periods, there will be propheteers and cowboys coming out of the woodwork to fill the void. It's quite easy to make a tiny tunneling protocol that's reasonably fast and does a few things; if you look on Github there are hundreds. It's quite another thing to write robust and secure software intend to last for a long time. That's what we're working on here. Fortunately we have two very nice projects that are rapidly approaching maturity: one in Go and one in Rust. I fully welcome future OSS authors into the project. When I'm back from visiting family at the beginning of April, I think we'll be in a good place to have a few first releases. I'll also do what I can to see that people aren't peddling junk and calling it wireguard, so as to reduce user confusion, but this of course isn't a very easy endeavor. I'm open to suggestions on how to approach this. Regards, Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard