Is this project DEAD?

[ava1ar]

I don't see any activity happening around this project for more that a half of the year. There are also a bunch of pull requests, which are ready to be merged, but they are not. There are also numerous security issues, reported by users in issues and nobody looking into addressing those. Does all this project is dead?

If someone know any fork, which is alive, please leave link here - GitHub reporting 1007 forks of the project, so there is a chance some of them are in better shape than original project is.

[dnobori]

Hello ava1ar,

I am the owner of this project. This project is not dead.

Since I want to keep the stability and functionality of SoftEther VPN, I need to review and test all patches submitted through Github or email. As my policy I have put the high priority on the stability and functionality than the rapidly merging of every submitted patches.

While I desire to perform them as soon as possible, my time to review them are very limited because this project is non-commercial and I have daily jobs to do in working days. Therefore, merging patches submitted from several contributors often needs some months especially when I am too busy.

As exceptions I respond to any critical vulnerabilities (e.g. privilege escalation or arbitrary code execution) as soon as possible which are reported through the security reporting email address. (the address is on the header of all source code files.)

Therefore, if you are in hurry to use some particular patches on the pull requests on this Github, you have three options:

1. Fork this project and apply patches to the destination project.
2. Apply patches to the local working directory to build your own binary.
3. Please be patient for next release.

Anyway it is very welcome that someone will have a forked project to maintain the "fast track" of SoftEther VPN, similar to fast track builds of Technical Preview of Windows 10.

[chipitsine]

well, on May 26 you asked me "one or two"

#229

I answered. and what happened ? nothing.
it would be really nice to hear something from you.

I beleive there was a reason os asking "one or two". And some action should happen after answer.

but it looks like project is rather dead. nothing happens. it is what people call "being dead"

[ava1ar]

dnobori,

I undestand your care about the stability and this is very important, but there is one thing, which is more important than stability - this is security. SoftEtherVPN is directly related to security and all security issues with the product should have super priority. But what I see instead - there are multiple reports about the security issues:

#120
#147
#179

and none of them are addressed within years! I.e. on Arch Linux I can't even build SoftEtherVPN without applying patches, since it already dropped SSLv3 support from its OpenSSL package. Also, due to luck of TLS 1.2 and SHA256 I can't connect to SoftEtherVPN using up-to-date OpenVPN client. I used to use SSTP for Windows client, but recently switched to Strongswan + IKEv2, since Strongswan supports certificate-based authentication.

When it first appeared in Open Source world, there was a lot of hope in community about this project, but now, years later almost no hope left. Is there any roadmap your are following to see what to expect in future? Will we get some usable interface for server administation from Linux? Will we get some usable Linux client? Will we get support for certificate authentication for protocol other than Ethernet-over-HTTPS?

Please don't get this post wrong - I am not blaming you or demanding anything right here and right now. I just want to say we as users and contributors need more clarify in project priorities and future in general. Hope you get my point.

[cenobitz]

Hello.

It is good that someone wrote this topic because I am worried about all good open source projects that one day will die leaving us with running apps on servers, desktops etc.

First read this article about patching bugs:
"lesson is that there needs to be more quality control on patches submitted through Github, because unfortunately there clearly is scope for a malicious actor to wreak havoc."
http://www.fionacoulter.com/blog/improving-quality-control/
this article is very popular by security researchers...

It is a cliché, but according to my knowledge every open source startup project ends when the person creating it is absorbed by commercial projects and there is no time for extra work. The same propably is with SE. As dnobori wrote he needs to review and test all patches and issues that is time consuming. SO the question is what we can do together to push this project further.

@ava1ar thanks for sharing knowledge about LINUX problems. We are testing several platforms, virtualization, server setups etc. and from about 2-3 months we got problems to setup any OPENVPN connection (which was working earlier this year) to SE VPN from several distros (mainly CentOS, Debian and it's clones). We lost several hours and I think it is shame that Linux doesn't have stable SE support. (I will test Strongswan)

I don't think that server administration for Linux is essential because CLI is very good in SE and for me the most important is to have more CLI features and some sort of API support than another admin panel.

[aicochow]

just donot die

[SplatterPaw]

I kinda gave up waiting for updates. There is sufficient information from all those tickets to fork your own high security build.

Things to update:
cipher_list entry needs to be updated to discard all insecure ciphers (most of them lol?)
Replace all those SSL_CTX_set_ssl_version calls with higher TLS versions in their arguments. No more SSLvn, low TLS, etc.

Basically if you don't do the above, your server will fail those SSL tests like Qualys (or get bad scores anyway).

Things to watch out for:
Those proto SSL_CTX calls mentioned in some of the tickets are from OpenSSL 1.1. They won't compile if your linux distro is still using 1.0.1.

Going down this path will require full client and server recompiles. All the users will need their software updated.

[baimafeima]

What is currently the best maintained fork?

[xortim]

I believe your answer is "yes":

• The "Issues" section is going to be closed at the end of the year, no replacement has been announced
• The forums are filled with spam posts
• Lots of PRs that haven't been acted upon.
• Time, this is a very complicated project. I'm sure the author(s) are simply busy with other projects that help them pay the bills.

[dnobori]

ava1ar,

#120 is not critical vulnerability. It is by design like a Windows security protocol on the CIFS includes the client computer's node information on the negotiation phase as the Windows server will log them on the security log, and so helpful to perfoem troubleshooting in the viewpoint of VPN server administrators in organizations. If there is a demand to change this client behavior it is very easy to disable it on the client side.

#147 and #179 is not critical vulnerability. Accepting SSLv3 by default is still necessary in this phase for backward compatibility since there are still users using SSLv3-only VPN clients in Japan. Also, any TLS-only VPN clients will never connect to the server in SSLv3 according my understand. Therefore virtually there are no practical threat on accepting SSLv3 in the present time. However, it is sure that disabling SSLv3 by default is important to enlighten users to do not use SSLv3. In fact, users using SSLv3 only clients are only in Japan. To balance both side of users, I need write some codes to decide the default behavior by the user's region or language, or ask the user to remain/disable SSLv3 at the installation point.

[SplatterPaw]

@baimafeima I didn't look. I merely built my own version using the source and following the responses to the tickets.

For us, we had to comply with PCI DSS 3.2. That meant that not even TLS 1.0 was allowed. The current release is coded to only attempt using TLS 1.0 when you disable SSLv3. So if you only recompiled the server to support TLS 1.2, the existing client will fail to connect. dnobori will basically need a have a new client version that steps through multiple protocol handshakes to handle backward compatibility while not falling over when connecting to higher security servers. I just didn't have the patience to do that and just tailored it to our requirements.

[dnobori]

For the "Issues" forum:

Currently, this project has two duplicated forums: Issues and VPN Users Forum. The actual usage of both forums are very similar. It is very inefficient for users to seek for / post to both forums to ask questions or post feature requests.

The VPN Users Forum has been active before I created this GitHub repository. Spam posts are bothering. While there is a problem of spam posts, spams are periodically removed, and the forum has some anti-spam script features to avoid them as possible.

[dnobori]

For the fundamental problem that this project is very slow in a certain perspective:

My policy to merging pull requests in this repository was wrote in my above comment. The stability and backward compatibility deserves than promptly merging, except critical vulnerability. While I am making my effort to increase speeds, some people have dissatisfaction to my pace.

Therefore, there are two possibilities I'd like to suggest:

1. I will create a fast track (development, unstable) repository on GitHub.
   The fast track repository will accept pull requests (roughly and promptly than the stable repository) with minimum security check.

2. Responsible volunteer (s) will create and own a forked repository for fast track. He (they) will manage it. I will announce that the new repository is SoftEther's official fast track repository. The new repository may inherit the "SoftEther" as the project name if he (they) decide it, or may change the name. He (they) will own the fast track project. I have no authority to manage the fast track project as a dictator.

In both choices, users can choose one of the two versions (stable or fast track). The difference between (1) and (2) is the responsibility and the redundancy. For redundancy and rapidness, I thought (2) is better than (1). In the choice (2), it will be virtually active successor of this project. The successor(s) will have the confidence from users.

Also there might be other ideas here.

I'd like to discuss.

[xortim]

Thanks for the updates on our concerns @dnobori. Just my two cents on this. The forums are pretty clunky and difficult to use, search, and follow. GitHub is much more welcoming and easier to use. To add to the usability, most users of free software that are willing to file bug reports already have a GitHub account or trust it to some extent. Maybe instead of general purpose forums that your team has to maintain, creating a subreddit might be more helpful. The purpose is not to move things around for convenience, but to hep make it easier and accessible for SE users to participate in a way that is productive and reduces the noise for everyone.

For the TLS related issues, I think the primary concern is more administrative control. For example, telling the server to only use TLS, and then to see SSLv3 pop up in the cipher list is concerning. I, personally, would like to see more control over the cipher list, and simply receive a warning in the GUI or CLI about backward compatibility issues. A lot of us have to comply with certain regulatory issues or auditing bodies, and this would definitely help us deploy and champion the project.

Thanks again for your work in making sure that the project remains current and stable.

[dnobori]

xortim,

Thank you for your comment. As you mentioned, I admit that the VPN Users Forum has a problem of comfort. The difficult problem is that I cannot rapidly respond to posted questions, troubleshooting requests and feature requests posted to Issues. A new solution for fundamentally reform is necessary as some people here are pointing out.

I would like to continue to discuss on this problem here to find a way to satisfy contributors and users.

[xortim]

dnobori,
While I can't necessarily help with the deep, code related issues with the project. I can, however, volunteer some time to help moderate a subreddit or forum, and assist with high-level usage related issues as time permits. I'm sure there are some other users that may be willing to pitch in, and help reduce the noise for you.

[xortim]

I think your fast track repository is a good solution to the problem. The biggest challenge is finding the right person or persons to take that on.

One suggestion is to start with option one (where you provide a development/unstable branch) and work with the top contributors on vetting an official forked project owner.

[dnobori]

xortim,

Thank you for your comment. If we start with option (1), I'd like to integrate all history to the new repository. I don't know well about GitHub, so I'd like to be advised if the following steps are possible.

1. Create a new repository by forking from this repository.
   (e.g. "SoftEtherVPN/SoftEtherVPNDev". Please suggest another good repository name,)
2. Integrate all posted issues and pull requests from this repository to the new repository.
   (Is it possible?)
3. Add some volunteers/contributors (if there are appropriate people) to the member of the project so that they can easily review and accept pull requests.
4. For a certain time later, I will transfer the owner authority to the appropriate successor (s) on the SoftEtherVPNDev repository (if there are appropriate successors).

[w1bsb]

to dnorbori, and contributors:

I have used OpenVPN for the last couple of years as it met my needs at the time. I stumbled across this project a couple of days ago and tested it out on my home lab. It is a very cool project, and it seems to work very well, and is very fast. I am glad to read it is not dead, and is still being worked on.

I compiled under Ubuntu 16.04 LTS w/ OpenSSL 1.0.x with the pull from #208. I am somewhat green to programming but know enough to be dangerous. I was hoping I could force TLS 1.2 connections only, but was unable to achieve that goal. Once I enforced TLS and disabled SSL V2, V3, and TLS 1, and 1.1, I could no longer connect with the client or GUI server manager under windows.

I look forward to seeing this project move forward however, more specifically, support for a TLS 1.2 only option for both server/client. Keep up the great work.

[SplatterPaw]

@cr9c1 Your mistake is that you only did a compile for the server version. The clients connect only with TLS 1.0, so you need to compile that same code under Windows to get new versions of the client and GUI.

If your current VPN client (NOT the VPN Server GUI) throws an error about protocol when connecting to your version of the Server, you are on the right path server-wise, and just need a re-compiled client.

[w1bsb]

@SplatterPaw Thanks -- I figured that may be the case. I had actually set out to take the same code to my visual studio machine, but I'm running 2015 Community and it didn't play well with it at all. Are you saying if I successfully compile the same code under VS 2008 that I did under Linux, it'll spit out some TLS 1.2 windows clients that will work?

[SplatterPaw]

Yes, you will need VS2008 and the required service packs as per the build instructions.

Both server and client codebases uses that Mayaqua/Network.c (assuming that is what you have changed).

[w1bsb]

I changed all the files from #208 yes. Thanks for the heads up, I'll give that a go and see how I fare.

[w1bsb]

I got it all compiled under VS2008/SP1 but still no go, will not connect to server with SSLV2/3, and TSLv1/v1.1 disabled on the server end, error code 2, protocol error.I appreciate the assistance you offered, though. It was worth a shot.

[SplatterPaw]

These are the changes I made for TLS. Pls match them up with the existing code before making the changes:

function -> *NewSslPipe

// Create a new SSL pipe
SSL_PIPE *NewSslPipe(bool server_mode, X *x, K *k, DH_CTX *dh)
{
    SSL_PIPE *s;
    SSL *ssl;
    SSL_CTX *ssl_ctx = NewSSLCtx(server_mode);

    Lock(openssl_lock);
    {
        if (server_mode)
        {
            SSL_CTX_set_ssl_version(ssl_ctx, TLSv1_2_server_method());

            AddChainSslCertOnDirectory(ssl_ctx);

            if (dh != NULL)
            {
                SSL_CTX_set_tmp_dh(ssl_ctx, dh->dh);
            }
        }
        else
        {
            SSL_CTX_set_ssl_version(ssl_ctx, TLSv1_2_client_method());
        }

Make sure you used the right arguments for the right sections.

function -> StartSSLEx

/*
            if (sock->AcceptOnlyTls == false)
            {
                SSL_CTX_set_ssl_version(ssl_ctx, SSLv23_method());
            }
            else
            {
                SSL_CTX_set_ssl_version(ssl_ctx, TLSv1_method());
            }
*/
            SSL_CTX_set_ssl_version(ssl_ctx, TLSv1_2_server_method());

            Unlock(openssl_lock);
            AddChainSslCertOnDirectory(ssl_ctx);
            Lock(openssl_lock);
        }
        else
        {
/*
            if (client_tls == false)
            {
                SSL_CTX_set_ssl_version(ssl_ctx, SSLv3_method());
            }
            else
            {
                SSL_CTX_set_ssl_version(ssl_ctx, TLSv1_2_client_method());
            }
*/
            SSL_CTX_set_ssl_version(ssl_ctx, TLSv1_2_client_method());
        }

In this part I am ignoring the checks and enforcing fixed restrictions (hence the chunks of code commented out).

[w1bsb]

Worked perfect, verified with a packet capture as well. Thanks so much!

[maurerr]

hi cr9c1,
can you share your builds and your code?
thanks

[w1bsb]

@maurerr The only changes I made were the changes proposed by @SplatterPaw
Aside from that, I also found a patch to add the ECDHE ciphers, and the build I'm working on right now currently has TLS v1.2 only, and ECDHE-RSA-AES256-GCM-SHA384 as the only cipher. I'm still figuring github out but if you want what I've got in the meantime, I can try to get it to you. I've got another patch I found to fix a memory leak with SSL I have yet to apply, but if you want I can email you what I've got so far, just let me know what you want (until I figure out how use this to upload code changes/differences/etc.

[maurerr]

zip archive with source code for linux would be fine - i can built my own bin from there.
but i havn't worked with vs2008 so i would need your windows binary build if you can post it.
thanks

[w1bsb]

I can do that. let me apply the SSL memleak patch real quick and build it and I'll see if I can get the zip archive uploaded of the linux source and the windows binaries.

[aenertia]

Nobori san, two branches master and devel is optimal way to achieve the outcome. I do not wish to track a second repository, and merging later will be more difficult.

…

On 29 November 2016 at 17:14, Daiyuu Nobori ***@***.***> wrote: Thank you. It could be great. But still I think dividing into two repositories would make it simple, avoiding problems, due to my Git skill. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#268 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARer7KsWFMcR7sDiKHrt6auj7UlgLrIks5rDM3ZgaJpZM4KqeJA> .

[dnobori]

Then it would be nice that I am going to fork this repository into a new second repository "SoftEtherVPN_Stable", and after that, use this current repository "SoftEtherVPN" as the primary development repository. All of this Issues forum and current pending pull requests will continue on the "SoftEtherVPN" repository.
The "SoftEtherVPN" repository will have appropriate committers other than myself, and will have more lightweight policy to accept pull requests and further modification. The goal is to make "SoftEtherVPN" having democratic management.
The "SoftEtherVPN_Stable" repository will have only single committer (myself), and will merge patches from the "SoftEtherVPN" manually only when I decide to do so.

Any comments are very welcome.

[chipitsine]

@dnobori , I think many people here can volunteer in maintaing git branches and help you with git flows. for example, I can.

I think it is good idea to move such activity to community

[dnobori]

Thank you, but I would like to divide the project into two repositories, like Fedora and RHEL. In this example, Fedora is the "SoftEtherVPN" repository. RHEL is the "SoftEtherVPN_Stable" repository. In other words, the stable repository is like a Long-Term Service Branch. "SoftEtherVPN_Stable" is the slow track build, and will be a conservative branch. In this purpose I think it is better to make an isolated "SoftEtherVPN_Stable" branch in GitHub rather than using branches in the single repository.

[dnobori]

In the above analogy, I'd like to move the activity for Fedora to the community, and would like to handle RHEL by myself. Users can individually choose one from the two forks. Most users will use the fast track builds, but small number of users (e.g. enterprise users) will prefer to use the stable and conservative builds. To fulfill both demands, it would be better that I will have the sole responsibility to ensure the integrity of the conservative build.

[moatazelmasry2]

@dnobori this is not a bad idea, especially if you want to be the sole maintainer of the stable repo, since github doesn't allow to assign maintainers to one branch only, but to the whole repo.

One issue that everyone should think of about the 2 repo solution is the issue tracker. People will probably submit the same issue twice and we need to come up with a solution that this does not happen (or minimize it)

[rwasef1830]

Solution: Disable opening issues in the stable repo, only open issues on the development repo. Issues would be opened in the development repo. Then a fixed in the development repo, then a patch applied on the stable repo (or cherry-pick). The development repo can have a branch that tracks the stable repo to ease preparation of the patch.

Then the maintainer of the dev repo, having prepared a patch applicable on the stable repo, sends it to @dnobori who can then apply it on the stable repo and release a new version as seen fit.

[moatazelmasry2]

Hmm. This could work, but what about errors that are in the stable repo but not in the dev repo. This could happen since patches will be applied here and there, so the code is not 100% identical.
I'm just trying to cover the bad scenarios here

[rwasef1830]

@moatazelmasry2 The dev repo would have a branch that is tracking the stable repo's main release branch, so people would just open issues there and say what version they were using like any other bug.

[dnobori]

Thank you for comments. I am considering to do the following things:

1. Create a new conservative repository named "SoftEtherVPN_Legacy" (this name is better than "SoftEther_Stable".)

• I will be the sole maintainer of "SoftEtherVPN_Legacy".
• I will import new feature from "SoftEtherVPN" to "SoftEtherVPN_Legacy" manually by my decision.
• I will import bug fixes from "SoftEtherVPN" to "SoftEtherVPN_Legacy" manually as soon as possible.
• The "Issues" and the "Pull Requests" will be hidden on the "SoftEtherVPN_Legacy" repository.

• I took the hint of the postfix "Legacy" from the Wireshark project. Wireshark has two branches: Wireshark (Modern) and Wireshark (Legacy). Wireshark Legacy is very conservative while the Modern is aggressive to improve its functionality.

2. Keep this current "SoftEtherVPN" repository without changing the repository name (to avoid confuse users by changing the URL.)

• I will call this repository as the "Modern" repository, in contrast to the "Legacy" repository.
• I will add some maintainers to this repository.
• I will also be one of the maintainers.
• Some delegated maintainers will have authority to control the source code, including accepting Pull Requests.

[dnobori]

For the official binary download site http://www.softether-download.com/, my idea is:

I will add two dropdown items "SoftEther VPN (Legacy)" and "SoftEther VPN (Modern)" on the top page.
I will share the credential to upload new binary files on this download site to some trusted maintainers.
Maintainers will be able to upload new builds to the download site.
Maintainers will have the credential to edit https://www.softether.org/ in real-time.

[iainhallam]

Legacy seems like it will be retired at some point leaving only the other repository - I definitely prefer Stable or Long Term Support, or even Enterprise, though that tends to imply extra features. The current repo seems like it could be labelled Testing, Development or Unstable.

There are precedents for this kind of naming, particularly with Debian: https://www.debian.org/releases/.

[dnobori]

Probably, Long Term Support sounds good. In this case the name will be "SoftEther_LongTerm".

[dnobori]

I suppose that the current repository should not labeled "Testing" or "Unstable". The current repository itself will have some branches, and "Testing" or "Unstable" should be just roles of some branches (not entire the repository.) Then labeling "Development" on the current branch is very appropriate in my sense.

[aenertia]

Master is normally considered development. This is the norm with say the Linux kernel. I agree a stable or release branch for the non-dev tree would also mimic the norm in other projects.

…

-Joel / @aenertia

On 30 November 2016 at 10:49, Daiyuu Nobori ***@***.***> wrote: I suppose that the current repository should not labeled "Testing" or "Unstable". The current repository itself will have some branches, and "Testing" or "Unstable" should be roles of some branches (not entire the repository.) Then labeling "Development" on the current branch is very appropriate in my sense. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#268 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARer3ifbBQseOqcQRuL_6RAUi8mMXU3ks5rDcUmgaJpZM4KqeJA> .

[moatazelmasry2]

Are there any updates on this issue? Should there be a vote or a decision soon? An unstable/test/development repo will really help push this project forward

[Erutan409]

I'd like to point this out. I kinda feel Github Issues is the better way to go. Just sayin' 😛

[kuituhirvi]

I have to say that this conversation has been great and also think that seeking advice from the Debian community way of doing things is a good idea. Let us just not get stuck on the precise wording as picking none or any for the two branches/repositories leaves the need for explaining the situation.

In Debian terms a release is always stable, so everything with a version number has to be stable. The newest (highest number) version is also supported, removing the need for a specific supported release. Testing for the next version is on-going and has no numbering although if one feels the need for such it could be conceived using simple arithmetics, with a formula like, latest release + 1.

Overall though these are very different kinds of projects and I feel that a singular (single use case) piece of software does not need to be as strict as Linux distribution and these kinds of labeling efforts can be approached a little more lightheartedly. Except for the piece considered stable for which I kind of like the term "Robust" as the term implies it is not easily penetrated.

[fenice2]

Is there any update on the progress of a 'fork' of this project?

[rwasef1830]

SoftEther is easily thwarted nowadays by DPI and throttling and fingerprint of unique SSL handshake. And especially UDP acceleration packet drop is used to disrupt SoftEther by letting first few packets and then dropping random packets (30-50% packet loss). It needs integration with KCP on UDP acceleration side, also it needs ability to set and change UDP acceleration port ranges (port range targeted and dropped by ISPs).

Also needed is built-in traffic obfuscation (for both tcp and also udp packets) to scramble packets using different methods (maybe integrate pluggable transports) or emulating HTTP packet to beat traffic shaping against long https sessions.

It is sorely in need of modernization.
Also it needs to be able to hide behind common nginx web proxy to camouflage with a normal website and use normal website https certificate.

[adminport]

This post is referenced here: https://opensource.com/open-organization/17/4/open-leadership-softether

[fenice2]

That's an interesting article and expresses the problem very clearly, unfortunately it offers no solutions. What can be done to move to a more dynamic model of development that will protect the life of the project and enhance the stability, reliability and security of the project?

There is, as far as I can see, no evident movement forward on the ideas expressed in this thread. In addition, the forums for SoftEtherVPN are a haven for spammers selling counterfeit goods, illegal goods, and various other nefarious products designed to separate a visitor from their hard earned cash.

[komlaetou]

This is such an interesting project that should stay alive as the ultimate alternative VPN solution. I am so sold that I have deployed this in production and boys, no regret. My only concern is the lack of clear sight sustainability of this project with Daiyuu Nobori being the only driver. And also there no information about the project roadmap anywhere on the official website nor on any forum.
@dnobori, can you offer us some update on this concern.
Cheers

[dnobori]

I'm sorry for my late response for the planning to fork this repository.
Because of my lack of capacity, my response to pull requests for this repository has been delayed frequently.

To solve this problem, I'd like to call three (or more) new development board members.

I posted the following thread. Please kindly read the self nomination process if interested.
#341

[fenice2]

That's fantastic news, I look forward to this project moving ahead - thanks for the update. :)

Unfortunately I'm not a developer so I can't do much in that area, any chance we could get some movement for the forums getting cleaned-up from all the spam/spammers on there?

[adminport]

#341

[adminport]

#341

New maintainer needed

[davidebeatrici]

I think that this issue can now be closed.