Top Related Projects
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:
-
Install SSLH on your system:
sudo apt-get install sslh
-
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"; } );
-
Start SSLH:
sudo systemctl start sslh
-
Configure your services to listen on their respective local ports, and SSLH will forward traffic accordingly.
Competitor Comparisons
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.
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.
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.
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 designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
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!
Top Related Projects
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot