SSF, a network tool with new features, performance and security in mind | Hacker News Reader

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

securesocketfunneling.github.io

62 pointsssfdeveloper21 comments

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

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.

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.

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.

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.

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.

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

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.

This was my concern too. I was hoping another HN'er might be able to shed some light on the reputation of the authors.

Good point, it's becoming harder to know how to establish trust in projects. Particularly things like security-related software, and software which opens network ports on your systems, where there's increased impacts if it turns out to be malicious/insecure.

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.

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

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

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

I think the last time I tested scp (with a large media file) over gigabit ethernet, ssh managed to saturate the link. Odd if that only holds for scp. Almost sounds as if the version of openssh used didn't use hw acceleration?

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

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)

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

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.

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

How is this different from stunnel?

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

Reply on news.ycombinator.com