Convert Figma logo to code with AI

yrutschle logosslh

Applicative Protocol Multiplexer (e.g. share SSH and HTTPS on the same port)

4,520
367
4,520
44

Top Related Projects

4,812

HAProxy Load Balancer's development branch (mirror of git.haproxy.org)

22,139

The official NGINX Open Source repository.

50,061

The Cloud Native Application Proxy

24,693

Cloud-native high-performance edge/middle/service proxy

Quick Overview

SSLH is a protocol demultiplexer that allows running several services on the same port. It listens on a single port and forwards incoming traffic to the appropriate service based on the protocol detected. This is particularly useful for sharing port 443 between HTTPS and SSH services.

Pros

  • Allows multiple services to share a single port, useful in restricted network environments
  • Supports a wide range of protocols including HTTPS, SSH, OpenVPN, tinc, XMPP, and more
  • Can be configured to work with fail2ban for improved security
  • Lightweight and efficient, with minimal impact on performance

Cons

  • May introduce a small latency overhead due to the protocol detection process
  • Configuration can be complex for advanced setups
  • Potential single point of failure if not properly managed
  • May require additional firewall configuration to work correctly

Getting Started

To get started with SSLH, follow these steps:

  1. Install SSLH on your system:

    sudo apt-get install sslh
    
  2. Create a configuration file /etc/sslh.cfg:

    verbose: false;
    foreground: true;
    inetd: false;
    numeric: false;
    transparent: false;
    timeout: 2;
    user: "sslh";
    pidfile: "/var/run/sslh.pid";
    
    listen:
    (
        { host: "0.0.0.0"; port: "443"; }
    );
    
    protocols:
    (
        { name: "ssh"; service: "ssh"; host: "localhost"; port: "22"; },
        { name: "ssl"; host: "localhost"; port: "443"; }
    );
    
  3. Start SSLH:

    sudo systemctl start sslh
    
  4. Configure your services to listen on their respective local ports, and SSLH will forward traffic accordingly.

Competitor Comparisons

4,812

HAProxy Load Balancer's development branch (mirror of git.haproxy.org)

Pros of HAProxy

  • More feature-rich and versatile, supporting advanced load balancing and proxying capabilities
  • Highly scalable and performant, suitable for large-scale deployments
  • Extensive documentation and active community support

Cons of HAProxy

  • More complex configuration and setup compared to SSLH
  • Higher resource consumption due to its broader feature set

Code Comparison

SSLH (simple configuration):

listen:
  - host: "0.0.0.0"
    port: "443"
protocols:
  - name: "ssh"
    host: "localhost"
    port: "22"
  - name: "tls"
    host: "localhost"
    port: "8443"

HAProxy (basic configuration):

frontend https-in
    bind *:443
    mode tcp
    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }
    use_backend ssh if !{ req_ssl_hello_type 1 }
    default_backend https-backend

backend ssh
    mode tcp
    server ssh 127.0.0.1:22

backend https-backend
    mode tcp
    server web 127.0.0.1:8443

While SSLH focuses on multiplexing SSL/SSH connections, HAProxy offers a more comprehensive solution for load balancing and proxying various protocols. SSLH provides a simpler configuration for specific use cases, while HAProxy's flexibility comes with increased complexity but greater scalability and features.

22,139

The official NGINX Open Source repository.

Pros of nginx

  • Highly scalable and performant web server and reverse proxy
  • Extensive documentation and large community support
  • Versatile with many built-in features and modules

Cons of nginx

  • More complex configuration compared to sslh
  • Heavier resource usage for simple port multiplexing tasks
  • Primarily focused on HTTP/HTTPS traffic, less flexible for other protocols

Code comparison

sslh configuration example:

listen:
(
    { host: "0.0.0.0"; port: "443"; }
);
protocols:
(
     { name: "ssh"; service: "localhost:22"; },
     { name: "http"; host: "localhost"; port: "80"; },
     { name: "ssl"; host: "localhost"; port: "443"; }
);

nginx configuration example:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    location / {
        proxy_pass http://backend;
    }
}

sslh is designed for simple protocol multiplexing on a single port, while nginx offers a more comprehensive web server and reverse proxy solution with advanced features. sslh is lighter and easier to configure for basic port sharing, whereas nginx provides greater scalability and functionality for complex web applications.

50,061

The Cloud Native Application Proxy

Pros of Traefik

  • More comprehensive reverse proxy and load balancer solution
  • Supports automatic HTTPS with Let's Encrypt integration
  • Offers dynamic configuration and service discovery

Cons of Traefik

  • More complex setup and configuration compared to SSLH
  • Higher resource usage due to its broader feature set
  • Steeper learning curve for beginners

Code Comparison

SSLH configuration example:

listen:
(
    { host: "0.0.0.0"; port: "443"; }
);
protocols:
(
     { name: "tls"; host: "localhost"; port: "8443"; },
     { name: "ssh"; host: "localhost"; port: "22"; }
);

Traefik configuration example:

http:
  routers:
    my-router:
      rule: "Host(`example.com`)"
      service: "my-service"
      entryPoints:
        - "websecure"
      tls:
        certResolver: "myresolver"

The code examples demonstrate the difference in complexity and functionality between SSLH and Traefik. SSLH focuses on simple protocol multiplexing, while Traefik offers more advanced routing and configuration options for a full-featured reverse proxy setup.

24,693

Cloud-native high-performance edge/middle/service proxy

Pros of Envoy

  • More comprehensive and feature-rich proxy solution
  • Supports advanced traffic management and observability
  • Highly extensible with a robust plugin ecosystem

Cons of Envoy

  • Higher complexity and steeper learning curve
  • Requires more resources to run and maintain
  • May be overkill for simple multiplexing needs

Code Comparison

sslh:

/* Simple protocol detection */
if (memcmp(buf, "\x16\x03", 2) == 0) {
    return PROTO_SSL;
} else if (memcmp(buf, "SSH-", 4) == 0) {
    return PROTO_SSH;
}

Envoy:

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 443 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager

sslh is a lightweight multiplexer designed for simple protocol detection and forwarding. It uses basic pattern matching to identify protocols and route traffic accordingly. Envoy, on the other hand, is a full-featured proxy with advanced configuration options and extensive capabilities for traffic management, load balancing, and observability. While sslh is easier to set up and use for basic multiplexing needs, Envoy offers more flexibility and power for complex networking scenarios but requires more resources and expertise to implement effectively.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

sslh -- A ssl/ssh multiplexer

sslh accepts connections on specified ports, and forwards them further based on tests performed on the first data packet sent by the remote client.

Probes for HTTP, TLS/SSL (including SNI and ALPN), SSH, OpenVPN, tinc, XMPP, SOCKS5, are implemented, and any other protocol that can be tested using a regular expression, can be recognised. A typical use case is to allow serving several services on port 443 (e.g. to connect to SSH from inside a corporate firewall, which almost never block port 443) while still serving HTTPS on that port.

Hence sslh acts as a protocol demultiplexer, or a switchboard. With the SNI and ALPN probe, it makes a good front-end to a virtual host farm hosted behind a single IP address.

sslh has the bells and whistles expected from a mature daemon: privilege and capabilities dropping, inetd support, systemd support, transparent proxying, chroot, logging, IPv4 and IPv6, TCP and UDP, a fork-based, a select-based model, and yet another based on libev for larger installations.

Install

Please refer to the install guide.

Configuration

Please refer to the configuration guide.

Transparent proxying

Transparent proxying allows the target server to see the original client IP address, i.e. sslh becomes invisible.

This means services behind sslh (Apache, sshd and so on) will see the external IP and ports as if the external world connected directly to them. This simplifies IP-based access control (or makes it possible at all), and makes it possible to use IP-based banning tools such as fail2ban.

There are two methods. One uses additional virtual network interfaces. The principle and basic setup is described here, with further scenarios described there.

Another method uses iptable packet marking features, and is highly dependent on your network environment and infrastructure setup. There is no known generic approach, and if you do not find directions for your exact setup, you will probably need an extensive knowledge of network management and iptables setup".

It is described in its own document. In most cases, you will be better off following the first method.

Docker image

How to use


docker run \
  --cap-add CAP_NET_RAW \
  --cap-add CAP_NET_BIND_SERVICE \
  --rm \
  -it \
  ghcr.io/yrutschle/sslh:latest \
  --foreground \
  --listen=0.0.0.0:443 \
  --ssh=hostname:22 \
  --tls=hostname:443

docker-compose example

version: "3"

services:
  sslh:
    image: ghcr.io/yrutschle/sslh:latest
    hostname: sslh
    ports:
      - 443:443
    command: --foreground --listen=0.0.0.0:443 --tls=nginx:443 --openvpn=openvpn:1194
    depends_on:
      - nginx
      - openvpn

  nginx:
    image: nginx

  openvpn:
    image: openvpn

Transparent mode 1: using sslh container for networking

Note: For transparent mode to work, the sslh container must be able to reach your services via localhost

version: "3"

services:
  sslh:
    build: https://github.com/yrutschle/sslh.git
    container_name: sslh
    environment:
      - TZ=${TZ}
    cap_add:
      - NET_ADMIN
      - NET_RAW
      - NET_BIND_SERVICE
    sysctls:
      - net.ipv4.conf.default.route_localnet=1
      - net.ipv4.conf.all.route_localnet=1
    command: --transparent --foreground --listen=0.0.0.0:443 --tls=localhost:8443 --openvpn=localhost:1194
    ports:
      - 443:443 #sslh

      - 80:80 #nginx
      - 8443:8443 #nginx

      - 1194:1194 #openvpn
    extra_hosts:
      - localbox:host-gateway
    restart: unless-stopped

  nginx:
    image: nginx:latest
    .....
    network_mode: service:sslh #set nginx container to use sslh networking.
    # ^^^ This is required. This makes nginx reachable by sslh via localhost
  
  openvpn:
    image: openvpn:latest
    .....
    network_mode: service:sslh #set openvpn container to use sslh networking

Transparent mode 2: using host networking

version: "3"

services:
  sslh:
    build: https://github.com/yrutschle/sslh.git
    container_name: sslh
    environment:
      - TZ=${TZ}
    cap_add:
      - NET_ADMIN
      - NET_RAW
      - NET_BIND_SERVICE
    # must be set manually
    #sysctls:
    #  - net.ipv4.conf.default.route_localnet=1
    #  - net.ipv4.conf.all.route_localnet=1
    command: --transparent --foreground --listen=0.0.0.0:443 --tls=localhost:8443 --openvpn=localhost:1194
    network_mode: host
    restart: unless-stopped
  
  nginx:
    image: nginx:latest
    .....
    ports:
      - 8443:8443 # bind to docker host on port 8443

  openvpn:
    image: openvpn:latest
    .....
    ports:
      - 1194:1194 # bind to docker host on port 1194

Comments? Questions?

You can subscribe to the sslh mailing list here: https://lists.rutschle.net/mailman/listinfo/sslh

This mailing list should be used for discussion, feature requests, and will be the preferred channel for announcements.

Of course, check the FAQ first!