Re: Tunsafe Windows client for wireguard (not opensource yet they say

Re: Tunsafe Windows client for wireguard (not opensource yet they say

[Ludvig Strigeus]

[-- Attachment #1: Type: text/plain, Size: 3761 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 15335 bytes --]

Re: Tunsafe Windows client for wireguard (not opensource yet they say

[Jason A. Donenfeld]

On Tue, Mar 6, 2018 at 2:44 AM, Ludvig Strigeus <strigeus@gmail.com> 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 the
best we can.

> You've
> ignored my attempts at communications for 2 weeks.

That's an odd thing to say. The last messages I have from you are you
indicating to me you're going to go the closed source way, and then
nothing after that for quite some time. In case IRC is irreliable for
me or for you, I prefer we speak privately over email --
jason@zx2c4.com usually works well these days.

> You ban me
> from #wireguard IRC even though I haven't talked there for weeks

As said prior, there's little interest in inundating users with
proprietary insecure software, not to mention freenode having some
policies about proprietary software. If you decide you'd like to open
source it at some point, rather than putting ads on it or selling it
like you've done in the past with software, we can talk. But insofar
as you're putting users in harm's way and fragmenting the project, I
ask that you stay away from these parts. Nobody is interested in
insecure software.

Yet in spite of your to-date brazenness, I'm still willing to work
with you if you'd like to turn things around. Shoot me an email if
you'd like to talk about open sourcing this work and integrating with
the community.

Regards,
Jason

Re: Tunsafe Windows client for wireguard (not opensource yet they say

[Steffan Karger]

Hi Ludvig,

On 6 March 2018 at 02:44, Ludvig Strigeus <strigeus@gmail.com> 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
security@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-devel@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

Re: Tunsafe Windows client for wireguard (not opensource yet they say

[Jason A. Donenfeld]

On Mon, Mar 5, 2018 at 12:19 PM, David Woodhouse <dwmw2@infradead.org> 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?

Re: Tunsafe Windows client for wireguard (not opensource yet they say

[Jason A. Donenfeld]

On Mon, Mar 5, 2018 at 12:29 PM, Sebastian Gottschall
<s.gottschall@dd-wrt.com> 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.

Re: Tunsafe Windows client for wireguard (not opensource yet they say

[Sebastian Gottschall]

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.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Tunsafe Windows client for wireguard (not opensource yet they say

[Sebastian Gottschall]

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.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Tunsafe Windows client for wireguard (not opensource yet they say

[Sebastian Gottschall]

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.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: Tunsafe Windows client for wireguard (not opensource yet they say

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

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.)

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: Tunsafe Windows client for wireguard (not opensource yet they say

[Henrique Carrega]

Just post to alert you:) don=E2=80=99t want to install:)


Sent from my iPhone

> On 5 Mar 2018, at 09:19, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>=20
> Hi Henrique,
>=20
> Thanks for posting this.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Regards,
> Jason

Re: Tunsafe Windows client for wireguard (not opensource yet they say

[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

Tunsafe Windows client for wireguard (not opensource yet they say

[Henrique Carrega]

[-- Attachment #1: Type: text/plain, Size: 134 bytes --]

https://tunsafe.com/

https://reddit.com/r/VPN/comments/82183o/tunsafe_a_high_performance_wireguard_vpn_client/
Sent from my iPhone

[-- Attachment #2: Type: text/html, Size: 449 bytes --]