[Package Update] sslh to 2.1.4

[lordvandal]

Software Name

sslh

Brief Description

Please update sslh package from from 1.21-6 (1.21c) to 2.1.4.

Thank you in advance!

There are some changes and enhancements in v2.x (https://github.com/yrutschle/sslh/blob/master/ChangeLog):

v2.0:

New sslh-ev: this is functionally equivalent to
sslh-select (mono-process, only forks for specified
protocols), but based on libev, which should make it
scalable to large numbers of connections.

New log system: instead of --verbose with arbitrary
levels, there are now several message classes. Each
message class can be set to go to stderr, syslog, or
both. Classes are documented in example.cfg.

UDP connections are now managed in a hash to avoid
linear searches. The downside is that the number of
UDP connections is a hard limit, configurable with
the 'udp_max_connections', which defaults to 1024.
Timeouts are managed with lists.

inetd merges stderr output to what is sent to the
client, which is a security issue as it might give
information to an attacker. When inetd is activated,
stderr is forcibly closed.

New protocol-level option `resolve_on_forward`,
requests that target names are resolved at each
connection instead of at startup. Useful for dynamic
DNS situations. (Paul Schroeder/milkpirate)

New probe for MSRDP (akappner).

Website

https://www.rutschle.net/tech/sslh/README.html

Documentation

https://www.rutschle.net/tech/sslh/README.html

Build/Installation documentation

https://github.com/yrutschle/sslh/blob/master/doc/INSTALL.md

Source code

https://github.com/yrutschle/sslh

OpenSource License

GPLv2

Other License

No response

[hgy59]

@lordvandal we already have sslh v1.22c, but it was not published.

I first will update to v1.23.1
The current version 2.1.4 does not compile and might need some patches (or will never be supported for DSM).

[lordvandal]

@hgy59 I understand and I very much appreciate your help. Thank you for your efforts!

[hgy59]

@lordvandal good news, all issues fixed and successfully created sslh-fork (aka sslh), sslh-select and sslh-ev.

shall we add sslh-select and sslh-ev to the package?

sslh is installed and runs as a service.
we can install all three variants, but only one of them for the service.
shall the package installation wizard ask whether to use sslh-fork (the same as before the update), sslh-select or sslh-ev for the service?
But if so, I guess we need to install different configuration files for each.

[lordvandal]

Hi @hgy59! That's wonderful! Thank you so much! You're my hero!

Could you please add sslh-select and sslh-ev if possible, to have all variants?
And maybe the wizard could ask which one to use, defaulting to sslh-fork?
Perhaps with the below short descriptions from the sslh install README in the selection dialogue?

The configuration is the same for all of them, so there only needs to be one configuration:

Binaries

The Makefile produces three different executables:
sslh-fork, sslh-select and sslh-ev:

• sslh-fork forks a new process for each incoming connection. It is well-tested and very reliable, but incurs the overhead of many processes. If you are going to use sslh for a "small" setup (less than a dozen ssh connections and a low-traffic https server) then sslh-fork is probably more suited for you.

• sslh-select uses only one thread, which monitors all connections at once. It only incurs a 16 byte overhead per connection. Also, if it stops, you'll lose all connections, which means you can't upgrade it remotely. If you are going to use sslh on a "medium" setup (a few hundreds of connections), or if you are on a system where forking is expensive (e.g. Windows), sslh-select will be better.

• sslh-ev is similar to sslh-select, but uses libev as a backend. This allows using specific kernel APIs that allow to manage thousands of connections concurrently.

[hgy59]

Could you please add sslh-select and sslh-ev if possible, to have all variants?

Those are already available in the latest build. You can manually download and install the package created by github build action as artifact.
Just copy sslh-ev over sslh or edit the SERIVCE_COMMAND in /var/packages/sslh/scripts/service-setup after installation.

The next step will be to add an installation wizard to choose the variant to use.
I guess the solution will be to keep the original name of sslh-fork and to create a symbolic link sslh to the variant selected in the wizard at installation time.

[hgy59]

@lordvandal latest update provides the wizard.
you can always use a manual update with the same package version to change the service variant.

[lordvandal]

I did some testing, and so far everything works fine.

I have the following 2 suggestions:

1. Updating /var/packages/sslh/var/sslh.cfg with the new version from https://github.com/yrutschle/sslh/blob/master/basic.cfg, with just changing the username: user: "sc-sslh", as some options have changed:

Starting sslh command /volume1/@appstore/sslh/bin/sslh -F/volume1/@appdata/sslh/sslh.cfg
Unknown settings:
/verbose:1
/timeout:5

2. Adding https://github.com/yrutschle/sslh/blob/master/example.cfg to /var/packages/sslh/var/, as (according to it) it is provided as documentation to show what is possible, and it contains lots of advanced configuration examples.
Probably the username change (user: "sc-sslh"`) would be useful - just in case.

[hgy59]

Unknown settings:
/verbose:1
/timeout:5

@lordvandal
I already removed those from sslh.cfg in the latest release.
On package updates the installed files in the var folder are always kept.
There is no update of the config file, but you find the updated version as sslh.cfg.new

The current config is almost the same as the basic example.

• don't know why basic also have the unsupported timeout configured
• package uses port 30000 instead of 443 (I guess to avoid conflicts with webstation, and DSM 7 prohibits the use of root i.e. privileged ports)
• listening on ipv6 is removed
• user, pidfile and logfile are defined for synology DSM integration

additionally I added the logging configuration taken from the example config (adjusted to use logfile only and to log config at startup) - this seems the replacement/refinement of the former verbose setting

the detailed log shows:

Landlock: not built in
capabilities: =

Do we need Landlock or additional capabilities?

[lordvandal]

@hgy59 variant selection works as a charm, tested.

We don't need Landlock, as it's one of the Linux Security Modules, and I believe it's not our concern on Synology.

[hgy59]

We don't need Landlock, as it's one of the Linux Security Modules, and I believe it's not our concern on Synology.

Yes, synology toolchains do not support it

checking for linux/landlock.h... no

[hgy59]

and capabilities seem to work:

when configuring transparent: true;
and enabling capability with sudo setcap cap_net_raw+pe /var/packages/sslh/target/bin/sslh-ev

the log shows:

capabilities: cap_net_raw=ep

setcap does not work with symbolic link sslh, but the real service works when started as link.

Since sllh is not started under root, the capabilities must be set manually before.

[lordvandal]

Yes, indeed, just checked. Cool, thanks!