Projects / sslh

sslh

sslh accepts connections in HTTP, HTTPS, SSH, OpenVPN, tinc, XMPP, or any other protocol that can be tested using a regular expression, on the same port. This makes it possible to connect to any of these servers on port 443 (e.g. from inside corporate firewalls, which almost never block port 443) while still serving HTTPS on that port.

Tags
Licenses
Operating Systems
Implementation

RSS Recent releases

  •  21 Dec 2012 03:00

    Release Notes: The OpenVPN probe has been corrected to support pre-shared secret mode (the OpenVPN port-sharing code is wrong). New features include an actual TLS/SSL probe, a configurable --on-timeout protocol specification, and an --anyprot protocol probe (equivalent to what --ssl was). Makefile now respects the user's compiler and CFLAG choices (falling back to the current values if undefined), as well as LDFLAGS. "After" and "KillMode" have been added to systemd.sslh.service. Standard LSB tags have been added to etc.init.d.sslh.

    •  08 May 2012 21:01

      Release Notes: This release supports a configuration file. New protocol probes can be defined using regular expressions that match the first packet sent by the client. sslh now connects timed out connections to the first configured protocol instead of 'ssh' (just make sure that SSH is the first defined protocol). It now tries protocols in the order in which they are defined (just make sure sslh is the last defined protocol).

      •  21 Apr 2012 21:52

        Release Notes: The default behavior of the --user and --pidfile options has been changed to not change the user or create a pidfile, if not specified. This simplifies integration with systemd and launchd. An HTTP protocol probe has been added.

        •  27 Nov 2011 21:57

          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.

          •  02 Aug 2011 21:21

            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.

            RSS Recent comments

            02 Feb 2010 07:54 yrutschle

            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 Avatar pgmglv

            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 yrutschle

            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 Avatar pgmglv

            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.

            Screenshot

            Project Spotlight

            beets

            A media library management system for obsessive-compulsive music geeks.

            Screenshot

            Project Spotlight

            reposurgeon

            A tool for editing version control repository history.