4 ms·

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

62 points by ssfdeveloper 11y ago

bscanlan 11y ago
Definitely looks interesting, but difficult to trust based on how it's been pseudo-anonymously dumped onto github in one commit.
- raesene4 11y ago
  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.
- laumars 11y ago
  This was my concern too. I was hoping another HN'er might be able to shed some light on the reputation of the authors.
- ssfdeveloper 11y ago
  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-linux 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-features 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.
  - bsaunder 11y ago
    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 11y ago
      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 11y ago
        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 11y ago
        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.
deleted 11y ago
[deleted]
zimbatm 11y ago
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 11y ago
  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/services/socks https://github.com/securesocketfunneling/ssf/tree/master/src...
  - ssfdeveloper 11y ago
    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-privately 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 https://securesocketfunneling.github.io/ssf/#performances) Thanks for digging into the code
ashmud 11y ago
How is this different from stunnel?
- ssfdeveloper 11y ago
  stunnel is an interesting software but it does not provide the same features. For the main part, it doesn't seem to multiplex connections.
ssfdeveloper 11y ago
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

62 points by ssfdeveloper 11y ago

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

raesene4 11y ago
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.
laumars 11y ago
This was my concern too. I was hoping another HN'er might be able to shed some light on the reputation of the authors.
ssfdeveloper 11y ago
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-linux 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-features 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.
- bsaunder 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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.

deleted 11y ago

[deleted]

zimbatm 11y ago

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 11y ago
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/services/socks https://github.com/securesocketfunneling/ssf/tree/master/src...
- ssfdeveloper 11y ago
  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-privately 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 https://securesocketfunneling.github.io/ssf/#performances) Thanks for digging into the code

ashmud 11y ago

How is this different from stunnel?

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

ssfdeveloper 11y ago

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