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. sslh supports IPv6, privilege dropping, transparent proxying, and much more.

Tags
Licenses
Operating Systems
Implementation

Recent releases

  •  23 Mar 2014 17:53

    Release Notes: Probes have been made more resilient to incoming data containing NULLs and now behave properly when receiving too-short packets to probe on the first incoming packet. Libcap support has been added to keep only CAP_NET_ADMIN if started as root with transparent proxying and dropping privileges (enable USELIBCAP in Makefile). This avoids having to mess with filesystem capabilities. Bugs related to getpeername which would cause sslh to quit erroneously have been fixed. IP_FREEDBIND is now set (if available) to bind to addresses which don't yet exist.

    •  27 Jul 2013 15:03

      Release Notes: The release adds transparent proxying so servers behind sslh see the connection as if it came from the outside, with its original IP address and port. It also corrects a couple of bugs which could crash sslh under heavy loads, especially in Cygwin.

      •  20 Dec 2012 19:55

        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 10:49

          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 17:01

            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.

            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 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 http://l7-filter.sourceforge.net/ - may be it will give you an idea. I posted a use case scenario at stackoverflow: http://stackoverflow.com/questions/795551/can-haproxy-front-both-web-servers-and-ssl-vpn-on-one-ip-and-port

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

            OpenStack4j

            A Fluent OpenStack client API for Java.

            Screenshot

            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.