

SSF, a network tool with new features, performance and security in mind - ssfdeveloper
https://securesocketfunneling.github.io/ssf/

======
bscanlan
Definitely looks interesting, but difficult to trust based on how it's been
pseudo-anonymously dumped onto github in one commit.

~~~
ssfdeveloper
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...](http://securesocketfunneling.github.io/ssf/#how-to-build-linux)

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...](http://securesocketfunneling.github.io/ssf/#security-features)

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

~~~
bsaunder
Could you be more specific on who "we" is (anonymous user created 3 hours
ago)? Rather than asserting trust is gained from simply open sourcing the
project.

~~~
ssfdeveloper
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.

~~~
bscanlan
Open source is definitely important part. The "trust" I was referring to was
deliberately ambiguous. There's not just leap of faith that potential users
have to make to ensure that there are no deliberate backdoors or flaws in this
software - there's also trust that this project will be cared and maintained
for over time: bugs will be acknowledged (and even fixed :) ), builds for new
platforms will work, security issues will be dealt with...

I'm not suggesting that bugs won't be fixed or there are backdoors, and this
is definitely a really interesting project. However there's just very little
to convince me that I should trust this project for anything more than a
throw-away experiment right now.

"the project was not initially meant to be OpenSourced"

Sounds like an interesting backstory - what's the motivation to open source it
so?

"Not being famous does not necessarily means being suspicious."

It's not being famous that matters here. Publishing software anonymously is
unusual (I'm sure there are exceptions here, however they're definitely
exceptions). Whenever I read of a new web service or software I generally dig
into who is behind it and why they're doing it. Code on its own does not
convince you to use it.

~~~
ssfdeveloper
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.

~~~
est
Haven't tested, but does SSF support handshake obfuscation? You know, some FW
has very intelligent traffic pattern fuzzing capabilities.

~~~
ssfdeveloper
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.

------
zimbatm
This looks great. Do you have any benchmarks that compare transfer speeds
compared to SSH ?

What is the canonical replacement to `tar czf - /some/folder | ssh user@host
"tar xvf -C /some/folder -"` ?

Key management could use a bit of doc, how do you generate all these keys ? It
would be nice to have a ssf-keygen tool.

Looking forward to see this gaining more traction.

~~~
e12e
It doesn't look like there is a replacement for that - it does however come
with a socks-server, appears to support both v4 and v5[1].

I wonder if there's still any real need to support both (but perhaps v5 layers
on top of v4, so it makes sense to implement them in layers, and little
overhead to provide both?). They have a howto-section on manually forwarding
dns - but socks5 really should be enough for most applications.

While a general forwarding tool will always be able to forward dns, from a
security and usability standpoint, it would seem just providing socks5 (and 5
only) might be better.

As for piping - as I mentioned it looks like there's no support built in - but
it should be possible to make a wrapper. Would need something on the other end
though - like a netcat that takes an output filename, and then spawns another
listener and redirects to a file or something.

I'd be interested in if there's any real performance differences between
openssh socks5/forwarding and this project. Especially since they build on the
same primitives.

[1]
[https://github.com/securesocketfunneling/ssf/tree/master/src...](https://github.com/securesocketfunneling/ssf/tree/master/src/services/socks)

~~~
ssfdeveloper
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...](https://securesocketfunneling.github.io/ssf/#how-to-browse-
privately)

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

Thanks for digging into the code

~~~
e12e
Which web browsers that aren't horribly outdated, doesn't support socks5?

~~~
ssfdeveloper
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)

~~~
e12e
Actually, after some google-ing, I'm not sure _any_ version of IE support
socks5?

------
ssfdeveloper
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

------
ashmud
How is this different from stunnel?

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

