From yves at rutschle.net  Sat Dec 31 17:14:07 2022
From: yves at rutschle.net (Yves Rutschle)
Date: Sat, 31 Dec 2022 17:14:07 +0000
Subject: [sslh] sslh v2.0-rc2 released
In-Reply-To: <20220607193520.GM2714@rutschle.net>
References: <20220607193520.GM2714@rutschle.net>
Message-ID: <20221231171407.GE15625@rutschle.net>

Hello all,

sslh-v2.0-rc2 is now available from the usual sources:
https://www.rutschle.net/tech/sslh/download.html
(and github, of course)

It fixes a vulnerability that got reported as CVE-2022-4639,
which was found and fixed by Toni. If you are using rc1,
please upgrade, or disable hex dump of incoming packets in
the log (which will render the vulnerability unreachable)

Happy new year!
Y.


On Tue, Jun 07, 2022 at 07:35:20PM +0000, Yves Rutschle wrote:
> Hello all,
> 
> sslh-v2.0-rc1 is now available from the usual sources:
> https://www.rutschle.net/tech/sslh/download.html
> 
> Here's the ChangeLog:
> 
> 	New sslh-ev: this is functionaly 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)
> 
> 
> Why 2.0? Because I feel like sslh has reached a stable point
> with a large amount of mature functionality, in particular with the
> inclusion of the libev version, and support for UDP
> protocols.
> 
> Why rc1? Because the UDP protocols, and in particular the
> hash-based lookups, need production testing.
> 
> Thanks in advance to all those who'll help with testing!
> Cheers,
> Y.
> _______________________________________________
> sslh mailing list
> sslh at lists.rutschle.net
> https://lists.rutschle.net/mailman/listinfo/sslh
>