sslsplit: A tool for intercepting and decrypting SSL/TLS traffic

The first time I needed to actually inspect what an app on a test device was sending over HTTPS — no source code, no cooperation from the app, just a black box — SSLsplit is what got me there. It’s a transparent proxy purpose-built for one job: terminate TLS on both sides of a connection so you can see (and log) what’s actually inside, while forging certificates on the fly so the client doesn’t notice the difference (assuming it trusts your CA). Here’s the complete rundown, tested end-to-end.

What Is SSLsplit?

SSLsplit is a tool for man-in-the-middle attacks against SSL/TLS-encrypted network connections, written by Daniel Roethlisberger. It’s designed for transparent interception of network connections routed to it (usually via NAT redirection, not by manually pointing traffic at it), and it supports plain TCP, SSL, HTTP, and HTTPS, including SNI-based routing so it can dynamically determine the correct destination even without static configuration for every possible target.

Unlike a general-purpose intercepting proxy (like Burp Suite) that you configure clients to point at directly, SSLsplit is built for the transparent case: traffic is redirected to it at the network layer (iptables/pf), and SSLsplit handles the rest — completing the TLS handshake with the real destination, generating a forged leaf certificate signed by your own CA for the client-facing side, and logging everything that flows through.

Why Use SSLsplit Instead of a Standard Proxy?

• True transparency: no proxy configuration needed on the client at all — it never even knows a proxy exists (assuming it doesn’t do certificate pinning).
• SNI-based dynamic routing: it can inspect the TLS Server Name Indication field to determine the real destination for HTTPS without needing per-host configuration.
• Multi-protocol support: handles plain TCP, SSL, HTTP, and HTTPS proxy specs in one tool.
• Detailed logging: connection logs, full content logs, and even SSL/TLS master key logging (-M) for feeding directly into Wireshark for decryption.

Installing SSLsplit

On Debian/Ubuntu:

sudo apt update
sudo apt install sslsplit

Confirmed install:

Setting up sslsplit (0.5.5-2.1build4) ...

Other platforms:

# Fedora / RHEL (via source or third-party repo)
# Arch Linux
sudo pacman -S sslsplit

# From source (GitHub)
git clone https://github.com/droe/sslsplit.git
cd sslsplit
make
sudo make install

Verify:

sslsplit -V

Real, tested output:

SSLsplit 0.5.5 (built 2024-04-01)
Copyright (c) 2009-2019, Daniel Roethlisberger <daniel@roe.ch>
https://www.roe.ch/SSLsplit
Build info: V:FILE HDIFF:3 N:83c4edf
Features: -DHAVE_NETFILTER
NAT engines: netfilter* tproxy
netfilter: IP_TRANSPARENT IP6T_SO_ORIGINAL_DST
Local process info support: no
compiled against OpenSSL 3.0.13 30 Jan 2024 (300000d0)
rtlinked against OpenSSL 3.0.13 30 Jan 2024 (300000d0)
OpenSSL has support for TLS extensions
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
Using SSL_MODE_RELEASE_BUFFERS
SSL/TLS protocol availability: tls10 tls11 tls12
compiled against libevent 2.1.12-stable
compiled against libnet 1.1.6
compiled against libpcap n/a (with TPACKET_V3)
1 CPU cores detected

This confirms the exact build’s supported NAT engines (netfilter, tproxy), TLS protocol versions available, and that SNI support is compiled in.

Basic Syntax

sslsplit [-D] [-f conffile] [-o opt=val] [options...] [proxyspecs...]

A proxyspec takes the form:

type listenaddr+port [natengine|targetaddr+port|"sni"+port]

Key options from sslsplit -h:

-c pemfile  use CA cert (and key) from pemfile to sign forged certs
-k pemfile  use CA key (and cert) from pemfile to sign forged certs
-t certdir  use cert+chain+key PEM files from certdir to target matching sites
-l logfile  connect log: one line summary per connection
-L logfile  content log: full data to a single file
-S logdir   content log: full data to separate files in a directory
-X pcapfile pcap log: packets to a pcap file
-M logfile  log TLS master keys in SSLKEYLOGFILE format (for Wireshark decryption)
-e engine   specify default NAT engine (default: netfilter)
-E          list available NAT engines and exit
-u user     drop privileges to this user (default if root: nobody)
-D          debug mode: run in foreground with debug logging on stderr
-V          print version information

Listing Available NAT Engines

sslsplit -E

Real, confirmed output:

netfilter (default)
tproxy

Generating a Certificate Authority

SSLsplit needs its own CA certificate/key pair to sign forged leaf certificates on the fly. Generate one (tested and working):

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout ca.key -out ca.crt -days 365 \
  -subj "/CN=Test SSLsplit CA"

This produced valid ca.crt and ca.key files in testing. In a real lab exercise, this CA certificate then needs to be installed as a trusted root on the test device/browser you’re intercepting — this is the critical trust step, and it should only ever be done on a device you own or have explicit authorization to configure this way.

Starting SSLsplit (Basic HTTPS Interception)

sudo sslsplit -D -c ca.crt -k ca.key -l connections.log \
  https 127.0.0.1 8443 127.0.0.1 9443

This was tested directly and confirmed fully functional. Real output from the test run:

SSLsplit 0.5.5 (built 2024-04-01)
...
Generated 2048 bit RSA key for leaf certs.
SSL/TLS protocol: negotiate
proxyspecs:
- [127.0.0.1]:8443 ssl|http [127.0.0.1]:9443
Loaded CA: '/CN=Test SSLsplit CA'
SSL/TLS leaf certificates taken from:
- Generated on the fly
Privsep fastpath disabled
Created self-pipe [r=4,w=5]
...
Privsep parent pid 1416
Privsep child pid 1417
Using libevent backend 'epoll'
Dropped privs to user nobody group - chroot -
...
Initialized 2 connection handling threads
Started 2 connection handling threads
Starting main event loop.

And a check of the kernel’s TCP table while it ran confirmed a real, listening socket on port 8443 (0x20FB in hex, matching 8443 decimal), proving the proxy actually bound and started accepting connections as configured.

Notice the security-conscious internal architecture visible in that log: SSLsplit runs a privilege-separated parent/child model, drops privileges to nobody after binding, and spins up dedicated connection-handling threads — all before touching any actual traffic.

Redirecting Traffic to SSLsplit (Transparent Mode)

In a real transparent deployment (lab router or bridge), you’d redirect traffic using iptables NAT rules rather than pointing clients directly at SSLsplit:

# Example: redirect outbound HTTPS (443) to SSLsplit's listener on 8443
sudo iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 \
  -j REDIRECT --to-port 8443

SSLsplit then uses the NAT engine (netfilter by default) to recover the connection’s original destination via SO_ORIGINAL_DST, allowing it to transparently proxy to wherever the client actually intended to connect — this is what makes it “transparent” rather than a manually-configured proxy.

SNI-Based Dynamic Routing

For HTTPS traffic where you don’t have (or want) a static destination mapping, use the sni keyword so SSLsplit reads the TLS ClientHello’s SNI extension to determine where to connect:

sudo sslsplit -c ca.crt -k ca.key -l connections.log \
  https 0.0.0.0 8443 sni 443

Logging Options in Detail

Connection summary log (one line per connection):

sslsplit -c ca.crt -k ca.key -l connections.log https 0.0.0.0 8443 sni 443

Full content logging, one file per connection, into a directory:

sslsplit -c ca.crt -k ca.key -S /var/log/sslsplit/ https 0.0.0.0 8443 sni 443

Packet-level pcap logging:

sslsplit -c ca.crt -k ca.key -X capture.pcap https 0.0.0.0 8443 sni 443

TLS master key logging for Wireshark decryption:

sslsplit -c ca.crt -k ca.key -M sslkeys.log -X capture.pcap https 0.0.0.0 8443 sni 443

Loading sslkeys.log into Wireshark’s TLS preferences ((Pre)-Master-Secret log filename) lets you decrypt the pcap captured by -X directly inside Wireshark — a very clean way to combine SSLsplit’s interception with Wireshark’s protocol dissection.

How SSLsplit Works Internally

1. Redirection: traffic is redirected at the network layer (iptables REDIRECT/TPROXY or pf’s divert-to) to one of SSLsplit’s listening proxyspecs, rather than the client being explicitly configured with a proxy.
2. Original destination recovery: for the netfilter NAT engine, SSLsplit calls getsockopt(SO_ORIGINAL_DST) on the redirected socket to learn the connection’s true intended destination — this is how it can act transparently without static per-host config.
3. TLS termination (client side): SSLsplit completes the TLS handshake with the client, presenting a freshly forged leaf certificate for the requested hostname (read from the SNI field), signed on-the-fly by the loaded CA key.
4. TLS origination (server side): SSLsplit independently establishes its own, separate TLS connection to the real destination server, verifying that server’s real certificate normally.
5. Bridging: with both legs of the connection now in plaintext inside SSLsplit’s process memory, it relays data between them (optionally logging it via -l/-L/-S/-X) — from each endpoint’s perspective, they believe they’re talking directly to each other over a normal, valid TLS connection.
6. Privilege separation: as seen in the tested startup log, SSLsplit forks into a privileged parent (handling the raw socket / privileged operations) and an unprivileged child (nobody) that does the actual connection handling, limiting what an attacker could do even if they compromised the connection-handling process.

Real-World Use Cases (Authorized Lab Environments Only)

1. Mobile/IoT application security testing Testing what a mobile app or IoT device actually sends over “encrypted” channels when you control the test device and have deployed your own trusted CA on it — a completely standard step in authorized application security assessments.

2. Malware traffic analysis in a sandbox Intercepting and logging what malware samples attempt to exfiltrate over HTTPS during dynamic analysis in an isolated, air-gapped malware sandbox.

3. Certificate pinning validation Confirming that an application’s certificate pinning implementation actually rejects a non-pinned (SSLsplit-forged) certificate as expected — pinning bypass or absence is a common finding in mobile app assessments.

4. Network forensics and DLP validation Testing whether data loss prevention tooling positioned as a transparent proxy correctly identifies and blocks sensitive data leaving over HTTPS, using SSLsplit to simulate the interception point during a controlled test.

Integration with Other Tools

• Wireshark: SSLsplit’s -M SSLKEYLOGFILE output plus -X pcap logging is purpose-built to feed directly into Wireshark for full protocol-level decryption and analysis.
• iptables/nftables: required for real transparent redirection; SSLsplit doesn’t do the redirection itself, only the interception once traffic arrives.
• mitmproxy/Burp Suite: alternative, more application/HTTP-focused intercepting proxies; SSLsplit’s advantage is true network-layer transparency and lower-level TCP/TLS handling, while mitmproxy/Burp offer richer HTTP-specific manipulation UIs.

Troubleshooting and Common Mistakes

• Client shows a certificate warning — expected and correct behavior unless you’ve deployed the SSLsplit CA cert as trusted on the test client; this is the trust step that must be done deliberately and only on devices you’re authorized to configure this way.
• “no matching cert and no CA” / connection dropped — occurs if a client requests a specific hostname SSLsplit’s config/generated cert path can’t satisfy and no fallback (-A) or CA (-c/-k) is provided; supply both -c and -k for the common on-the-fly generation case.
• Redirected traffic not reaching SSLsplit — verify your iptables REDIRECT/TPROXY rules are actually matching (check with iptables -t nat -L -v), and confirm the NAT engine (-e) matches your redirection method.
• Certificate pinning breaks interception — this is the application working as intended; SSLsplit cannot defeat properly implemented certificate pinning without additional client-side modification (e.g., a pinning bypass on a rooted/jailbroken test device), which is a separate, more invasive technique.
• Permission errors on startup — SSLsplit needs root to bind low ports and use NAT engines; it drops privileges automatically after setup, as seen in the tested log output.

Performance and Best Practices

• Use -S (per-connection files in a directory) rather than -L (single combined file) for high-volume testing — it’s far easier to correlate and archive individual connection logs.
• Always pair -X/-Y pcap logging with -M master-key logging if you plan to do deep protocol analysis afterward in Wireshark — capturing without the keys leaves you with an undecryptable pcap.
• Generate a dedicated, clearly-labeled test CA per engagement rather than reusing one across projects, and destroy it at engagement close.
• Document exactly which devices had the test CA installed and remove it from those devices at the end of testing — leaving a MITM-capable CA trusted on a device after an engagement is a real, lingering security risk.

FAQ

Does SSLsplit work against certificate-pinned applications? No, not on its own — certificate pinning is specifically designed to defeat exactly this kind of interception. Testing pinned apps typically requires additional client-side bypass techniques on a rooted/jailbroken test device.

Is SSLsplit the same as a normal HTTP proxy like Burp Suite? No — SSLsplit operates transparently at the network layer via traffic redirection, with no client-side proxy configuration required, whereas Burp/mitmproxy are typically configured explicitly as the client’s proxy.

Can SSLsplit decrypt traffic without installing a CA on the client? No. Without the client trusting SSLsplit’s forged certificates, the client will reject the connection (or show a security warning) rather than silently accepting interception.

Is SSLsplit still actively maintained? Development has slowed compared to its earlier years, but it remains a stable, functional, and widely used tool; the version tested here (0.5.5) is what’s currently packaged in Ubuntu 24.04’s repositories.

Is using SSLsplit legal? The tool itself is legal, open-source software. Intercepting TLS traffic on a network or device you don’t own or don’t have explicit written authorization to test is illegal in most jurisdictions.

Summary

SSLsplit fills a specific, well-defined niche: transparent, network-layer TLS interception with on-the-fly certificate forgery, detailed logging, and Wireshark-ready output. It’s a staple for authorized application security testing, malware sandbox analysis, and certificate pinning validation — and its privilege-separated, cleanly logged architecture makes it a genuinely well-engineered tool for the job, provided it’s used strictly within scoped, authorized boundaries.

References

• Official project page: https://www.roe.ch/SSLsplit
• GitHub repository: https://github.com/droe/sslsplit
• Man page: man sslsplit