sslh accepts HTTPS, SSH, OpenVPN, tinc, and XMPP connections on the same port. This makes it possible to connect to any of these servers on port 443 (e.g., from inside a corporate firewall, which almost never blocks port 443) while still serving HTTPS on that port.
| Tags | Networking Firewalls Internet Proxy Servers |
|---|---|
| Licenses | GPL |
| Operating Systems | Unix POSIX Mac OS X |
| Implementation | C |
Recent releases


Release Notes: This release now works with FreeBSD and supports XMPP. It will try target addresses in turn until one works if there are several (e.g., "localhost:22" resolves to an IPv6 address and an IPv4 address and sshd does not listen on IPv6). sslh-fork has been fixed so that killing the head process kills the listener processes. This release introduces a better test suite.


Release Notes: This release supports IPv6, has more comprehensive logs, introduces long options, adds binding to multiple addresses, and supports tinc (experimental). Warning: options have changed, and you'll need to update your start-up scripts. The log format has changed, and you'll need to update log processing scripts.


Release Notes: This release adds a single-threaded, select(2)-based version. It adds -o "OpenVPN" and OpenVPN probing and support. It adds support for "Bold" SSH clients (clients that speak first, e.g. ConnectBot). The log format has been changed to make it possible to link connections to subsequent logs from other services. The CentOS init.d script has been updated. A zombie issue with OpenBSD has been fixed. An -f "foreground" option, a test suite, and README.MacOSX have been added. Use with proxytunnel and corkscrew is documented in the README.


Release Notes: This release adds a CentOS init.d script, fixes a default SSL address inconsistency (it now defaults to "localhost:443", and the documentation has been fixed accordingly), no longer binds children to the listening socket (so a parent server can be stopped without killing an active child), and adds inetd support.


Release Notes: This release adds -V, a version option. The install target directory is configurable in the Makefile. The syslog prefix in auth.log has been changed to "sslh[%pid]". A man page has been added. There are new 'make install' and 'make install-debian' targets. The PID file is now specified using the -P command line option. Aombie generation has actually been fixed (the v1.5 patch was lost).
Recent comments
02 Feb 2010 07:54
Ok, as a security consultant the idea of doing level-7 filtering in kernel space almost made me lose my breakfast -- one vulnerability in your code and you're giving away the entire shop. To be honest, I already feel like all of iptables should be done in user space.
To quote D.Knuth, "premature optimization is the root of all evil": I would really suggest trying it out and profiling first to confirm that sslh is indeed too slow. I think you're overestimating the cost of forking (it's very low in Linux).
If it turns out to be a bottleneck indeed, then I'd look at zero-copy (I remember there is a Linux-specific system call to tell the kernel to copy from one fd to another, thus you save the additional copying.). With that, the only overhead of sslh would be the forking, and even that could conceivable be removed.
Doing things in kernel space for the sake of performance, sorry, no. There has once been a kernel-space Web server in Linux: no-one used it, and the world went on with user-space Web servers, for good reasons.
02 Feb 2010 00:47
Got it, your approach of creating a process per connection is ok for light use. Yet, the coolest thing SSLH could do is insert itself as filter for iptables. This way SSLH would not need to spawn a process and will not even need to do a memory copy. This is a nirvana of scalability. Take a look at l7-filter.sourceforge.... - may be it will give you an idea. I posted a use case scenario at stackoverflow: stackoverflow.com/ques...
01 Feb 2010 13:48
Basically for each incoming connection, a new process is started that shovels data from the outcoming socket to the internal socket. Cost is one memory copy.
I don't expect sslh would be a bottleneck in normal usage -- establishing https connections would typically have a much higher CPU cost than sslh processing. However, I don't think it's ever been used in such an environment, so no guarantees. If you do try it, let me know how it goes.
21 Dec 2009 20:23
I am thinking of using sslh on Amazon EC2 server. Can you please tell me if sslh can handle high volume of requests and large volumes of data? It would be great to understand sshl's architecture - how it passes the connections to the target.