Hacker News Reader

ssfdeveloperon SSF one year later: cross platform shell, proxy support and new features

We unveiled the SSF project about one year ago and we wanted to make a retrospective on its evolution since then.

SSF is a network tool and toolkit. Its first version was released in June 2015 and we released 2.2.0 a week ago. Here are some highlights of the project activity:

# Cross platform Shell

A feature we wanted to provide in a new version was a cross platform shell. At the moment, the shell feature makes it possible to interact with cmd.exe on Windows and bash on Linux/OS X (default settings). Actually, the shell is completely customizable, so it is possible to set Powershell or whichever shell is available on the machine.

Shell feature is not enabled in the default configuration, you must enable it explicitly in the configuration file. At the moment, this feature is quite different from SSH: this is only the first draft! It will be improved over time.

# Proxy

Some users requested support for connection through HTTP proxy (CONNECT), so we implemented it. SSF also supports proxy authentications such as Basic, Digest, NTLM (Windows only) and Negotiate. Windows NTLM and Negotiate authentications are based on SSPI and Linux/OS X Negotiate authentication is based on the GSS API.

# Transport protocol enhancement

After taking a step back, the process of establishing a connection was clearly not modular enough. Indeed, some users wanted to establish a connection through a proxy, we wanted to add an extra encryption layer on top of the relay layer... As a result, rewriting this component took us a lot of time.

SSF business logic (multiplexing, microservices, features) is transport agnostic. It relies only on the Boost.Asio API (acceptor and stream socket interfaces). This means that the transport logic can be easily replaced by anything which complies with those APIs, at minimal cost. We have a side project that is a Boost.Asio UDT implementation (stream over UDP, development is currently in its very early stage). In a near future, we could imagine to have SSF use TLS over UDT.

# Target platform: Windows >= Vista, Debian >=6

We improved the build process to support more platforms. Now, prebuilt binaries can be run without any dependencies on:

* Debian >= 6 (32/64 bits): limitation resides in the GLIBC version (2.9 required at the moment)

* Windows >= Vista (32/64 bits): Workaround for Windows XP is to select the XP toolset before building the project. XP support is planned for a next release.

# What's next?

This project is still young. We appreciate feedback and new ideas.

Shell will be the first feature that we will improve. Supporting connection through SOCKS proxy is also planned.

We put aside the UDT library to focus on SSF but we think this lib really has some potential so we may resume its development.

Feel free to join the adventure :-)

ssfdeveloperon SSF, a network tool with new features, performance and security in mind

Older versions of Internet Explorer did not support SOCKS5 and Chrome uses SOCKS4 by default (although you can manually specify --proxy-server="socks5://" to force SOCKS5)

ssfdeveloperon SSF, a network tool with new features, performance and security in mind

By the way, we just fixed a build system bug after an issue was reported. If you had any trouble building, please git pull and try again

ssfdeveloperon SSF, a network tool with new features, performance and security in mind

SSF supports SOCKS v4, v4a and v5 (only main SOCKS features that were implemented in SSH). All these versions are necessary for supporting as many web browsers as possible. Old browsers using SOCKS v4 would need to use UDP forwarding for DNS resolving (to avoid leaking DNS request locally). As you mentioned, there is a "how to" section on the website: https://securesocketfunneling.github.io/ssf/#how-to-browse-p...

For a simple comparison between SSH and SSF performances, you can take a look at the website (https://securesocketfunneling.github.io/ssf/#performances)

Thanks for digging into the code

ssfdeveloperon SSF, a network tool with new features, performance and security in mind

Thank you for your interest for our project.

There is a page on the website with a benchmark between SSF and SSH. It is a little bit basic. The test is done on TCP port forwarding.

Concerning your use case, it would be interesting to support it. We will look into it. It might not be straightforward to make it crossplatform.

Regarding the key generation, there is a tutorial on the website (https://securesocketfunneling.github.io/ssf/#security-featur...). We also have our own script to generate test keys. We can make it more user-friendly and publish it.

ssfdeveloperon SSF, a network tool with new features, performance and security in mind

stunnel is an interesting software but it does not provide the same features. For the main part, it doesn't seem to multiplex connections.

ssfdeveloperon SSF, a network tool with new features, performance and security in mind

Currently, SSF only supports standard TLS 1.2 handshake but the new networking design will allow to add new protocols easily. The tunnel implementation (currently TLS over TCP) will be modifiable without impacting the higher networking layers.

ssfdeveloperon SSF, a network tool with new features, performance and security in mind

We are eager to receive reviews and improvements. We have been working on this project for a while and we have no intention to stop now. A motivation for opensourcing it was to get feedbacks and even contributors from community. Every contribution (bug reports, feature requests) will help us to improve the software and that's exactly what we are looking for at this point. We know that trust is a long term process and we invite you to follow the project and give us any feedback that could help us to make the software better.

We are currently planning and working on new features. Right now, we are focusing on making the networking part even more modular and extendible (e.g. a transport layer based on UDP rather than TCP). Moreover, an other goal we would like to reach is to make the global framework simpler so that contributors could add to SSF their own features quickly and easily.

ssfdeveloperon SSF, a network tool with new features, performance and security in mind

The code is OpenSource so that anyone can review it. IMHO, that's one of the best way to gain trust.

But since you asked, "we" are two Belgian C++ enthusiasts happy to contribute to OpenSource community that gave us so much.

We have been working on this project for a couple of years and we are very excited to release it.

ssfdeveloperon SSF, a network tool with new features, performance and security in mind

Thanks for the interest you've shown for this project.

About the yet-single push : the project was not initially meant to be OpenSourced. Next commits will be more frequent, with more details.

About your concerns regarding trust: that's one of the strongest motivation for developing and OpenSourcing this project. Pre-built binaries can be tested against your own build. A lot of work was done to make the build a really straightforward process. Most of the complexity of building and linking third-party libraries (e.g OpenSSL or Boost) is contained (local to the project) and automated.

By the way, SSF-Cmake scripts are really useful, and could be used by anyone, in any project.

More details : http://securesocketfunneling.github.io/ssf/#how-to-build-lin...

The cryptographic part is entirely based on OpenSSL (latest version), and depends on sources only. SSF only supports latest TLS-1.2 and default cipher suite is DHE-RSA-AES256-GCM-SHA384 (RSA based authentication, perfect forward secrecy enabled, AES 256 based symmetric cipher in Galois Counter Mode). The RSA key sizes depends on you.

More details : http://securesocketfunneling.github.io/ssf/#security-feature...

Not being famous does not necessarily means being suspicious. We are open to any suggestion regarding the project, build-system or trust issues.