Everything you need to deploy, monitor, and splice TLS connections.
The typical journey from install to PQC migration:
No SSH after install. No config files to edit. The dashboard controls everything.
Register at tlslane.com/register to get your agent token and install command.
The script auto-detects your OS, architecture, and distro (via /etc/os-release and glibc version). RHEL 8, CentOS 8, and Amazon Linux 2 are automatically detected and get the -el8 binary. Use --el8 to override if auto-detection is wrong (containers, chroots). Omit --yes to get a confirmation prompt (requires interactive shell, not curl | sh).
For manual installation, choose the correct binary for your system:
/etc/tlslane/token since the agent typically runs as a system daemon. You can also pass it via --token flag or TLSLANE_TOKEN environment variable.The same token works on every host. Each host registers as a separate agent with its own hostname. Run the same install command on each machine:
The install script auto-detects OS, architecture, and glibc version, then downloads the correct binary.
For fleet tools that need explicit binary URLs:
| Binary | Targets |
|---|---|
tlslane-linux-amd64 | RHEL 9+, Debian 12+, Ubuntu 22.04+, Fedora 37+, Amazon Linux 2023 |
tlslane-linux-amd64-el8 | RHEL 8, CentOS 8, Amazon Linux 2, Ubuntu 18.04+, Debian 10+ (proxy mode only) |
All agents appear on your Hosts dashboard page.
After install, agents start in monitor mode. This observes TLS handshakes and reports cipher suite, version, and key exchange information.
Uses eBPF/TC to passively read packets off the network interface. Traffic is not modified or terminated. Sees all TLS connections on the host transparently, no per-application configuration needed.
On systems where inline mode is not available (non-Linux, kernel < 4.9), proxy mode can be used as a fallback:
Output (both modes):
Each line shows the server's negotiated TLS version, key exchange group, and cipher suite. This data is batched and sent to your dashboard every 30 seconds.
Splice mode performs two independent TLS handshakes on each connection, upgrading the cryptography between client and server.
You can enable splice from the Hosts dashboard (see Remote Mode Control) or from the command line:
sudo tlslane ca generate then sudo tlslane ca trust before splicing.Inbound connections are those where external clients connect to your service — you are the server. The agent needs a real server certificate for these so clients trust the connection without installing the TLS Lane CA. For outbound connections (your service connecting to external servers), the agent uses a CA-signed certificate automatically — no configuration needed.
To provide your own server certificate for inbound splice:
For multiple domains, use config.yaml:
Domains are extracted automatically from each certificate's CN and Subject Alternative Names. The matching cert is selected by SNI (exact match first, then wildcard). Outbound connections continue to use the CA-signed approach.
For fleets where each host serves the same domain (e.g. behind a load balancer), provision the cert alongside the install:
For hosts with their own Let's Encrypt certificates:
The Certificates page lets you distribute a server certificate to online agents without SSH access. This is useful for fleets behind a load balancer that share a wildcard or SAN cert.
How it works:
0600 permissions in ~/.tlslane/certs/.Cert push is not a PKI engine — it does not issue, rotate, or revoke certificates. Bring your own cert from any CA or ACME provider. For full certificate lifecycle management (issuance, rotation, revocation), use an external secret manager and provision certs via config or Ansible.
The Hosts page shows every host running tlslane under your account:
| Column | Description |
|---|---|
| Status | online (heartbeat within 90s) or offline |
| Hostname | Machine hostname (from system) |
| OS | Operating system and kernel version |
| Version | tlslane binary version |
| Hosting | Auto-detected: cloud or on-prem |
| Mode | Current mode: monitor or splice |
| Flows | Active TLS flows being tracked |
| Errors | Splice errors (handshake failures) |
| Disk | Agent disk free percentage. Red <5%, amber <10%. |
| Last Seen | Last heartbeat (every 30 seconds) |
The Crypto Inventory page shows your fleet's cryptographic posture at a glance.
Four cards at the top show total domains observed and the breakdown by risk level:
A progress bar shows PQC migration status as a percentage of total connections.
Click a hostname button above the summary to see only that host's inventory. Summary cards and progress bar update to reflect the selected host. Click "All hosts" to return to the aggregate view.
The table is sorted by risk (legacy first, then modern, then PQC) so the most urgent items are always at the top.
| Column | Description |
|---|---|
| Risk | Classification: legacy, modern, or pqc |
| Direction | inbound — external clients connecting to your service (you are the server). outbound — your service connecting to external servers (you are the client). |
| Domain | Domain name observed in the TLS handshake (SNI) |
| Tag | System classification (e.g. payment, email, identity) |
| TLS Version | Server-negotiated TLS version |
| Key Exchange | Key exchange group (P-256, X25519, ML-KEM-768, etc.) |
| Cipher | Server cipher suite |
| Cert | Server certificate key type and size (e.g. ECDSA-256, RSA-2048). Available in splice mode. |
| Action | monitor, spliced, passthrough, or blocked |
| Count | Number of connections |
| Last Seen | Most recent connection timestamp |
Domains are automatically classified by system type (email, payment, identity, CDN, analytics, storage) based on built-in patterns. You can add custom tags at the bottom of the crypto inventory page using glob patterns (e.g. *.stripe.com → payment). Custom tags override auto-classification. Tags are used on the Compliance page to show PQC readiness by system.
The Alerts page shows automatically generated alerts. Two types are always active:
Configure a webhook URL on the Alerts page to receive a JSON POST for each new alert. Works with Slack, PagerDuty, Zapier, or any HTTP endpoint.
Alert types: agent_offline, legacy_crypto, cert_expiry, disk_space.
#ops-alerts) and click Add Incoming WebHooks integrationhttps://hooks.slack.com/services/...)Slack displays the raw JSON payload. For formatted messages, use a Slack Workflow to transform the webhook into a rich notification.
Groups let you organize agents by hostname pattern. Create groups on the Hosts page.
Patterns use glob syntax: web-prod-* matches web-prod-01, web-prod-02, etc. Agents are matched automatically — new agents that match the pattern are included without configuration.
Groups are used for:
Policy controls which domains are spliced, passed through, or blocked when an agent is in splice mode. Use the dashboard policy editor or create a local policy.yaml:
| Action | Description |
|---|---|
splice | Perform independent TLS handshakes, upgrade crypto |
passthrough | Forward traffic unmodified (monitored only) |
block | Drop the connection |
Patterns support * (single level) and ** (any depth) wildcards. Dashboard policy overrides local policy.yaml.
If you have agent groups, the policy page shows group tabs at the top. Select a group to edit its policy. Agents receive the most specific policy that matches their hostname:
The policy page offers predefined templates to get started quickly:
| Template | Description |
|---|---|
| Monitor Only | Passthrough all traffic — observe without splicing |
| Splice All | Splice everything with PQC, no exceptions |
| Conservative | Passthrough known cert-pinning domains (Apple, Google, Microsoft, AWS), splice the rest |
| CNSA 2.0 | Compliance-focused — passthrough Apple/iCloud, splice everything else for PQC upgrade |
Click a template to load it into the editor, then customize and save. Templates are available per-group — different groups can start from different templates.
Every save creates a version. The version history at the bottom of the policy page shows all previous versions with a show button to view the full YAML. Click rollback to restore a previous version. Each group has its own independent version history.
Click "Generate from inventory" to auto-classify domains based on observed crypto. Legacy and modern domains get splice, PQC domains get passthrough. Review and edit before saving.
Agents poll for policy changes every 60 seconds. For local policy, send SIGHUP to reload: kill -HUP $(pidof tlslane)
The Target column on the Hosts page lets you switch agent modes from the dashboard:
| Setting | Description |
|---|---|
local | Agent uses its own configuration (default after install = monitor) |
monitor | Force monitor mode from dashboard |
splice | Force splice mode from dashboard |
The agent picks up the target mode on its next config poll (within 60 seconds). Combined with policy:
Update agents from the command line or remotely from the dashboard.
Downloads the latest version, verifies the SHA256 checksum, backs up the current binary, and replaces it. Use tlslane update --rollback to restore the previous version.
0.5.4) in the Update column for one agentAn amber badge on "Hosts" in the sidebar shows how many agents are running an older version than the latest release.
If a new binary crashes on startup, the agent automatically restores the previous version on the next restart. This is handled via a .updating marker file — no manual intervention needed.
TLS Lane helps organizations meet post-quantum cryptography regulatory requirements by providing continuous cryptographic inventory, audit trails, and migration tracking.
| Regulation | Requirement | How TLS Lane Helps |
|---|---|---|
| CNSA 2.0 | New NSS acquisitions PQC-compliant by 2027, full migration by 2033 | Continuous monitoring identifies non-compliant connections. PQC migration progress bar tracks adoption over time. |
| OMB M-23-02 | Annual cryptographic inventory with 9 data items per system | Automated inventory of domains, TLS versions, cipher suites, and key exchange groups. Export as NDJSON for reporting. |
| NSM-10 | Federal agencies must mitigate quantum risk by 2035 | Risk classification (legacy/modern/PQC) per domain. Policy engine enables targeted splice upgrades. |
| CISA ACDI | Automated cryptographic discovery and inventory | eBPF-based passive discovery requires no agent on target systems. Covers data-in-transit across the network. |
| Authority | Requirement | How TLS Lane Helps |
|---|---|---|
| 數位發展部 (MODA) | Published Taiwan's first PQC Migration Guide (後量子密碼遷移指引, April 2025). Recommends organizations inventory cryptographic systems and plan migration. | Automated cryptographic inventory with risk classification. Continuous monitoring covers all TLS traffic without manual collection. |
| 金管會 (FSC) | Financial Cybersecurity Resilience Blueprint (金融資安韌性發展藍圖, Dec 2025). PQC migration reference guide for financial institutions targeted H1 2026. | Audit trail with append-only event logs for compliance evidence. Export as NDJSON for regulatory reporting. |
| 金管會 PQC Pilot | Pilot group of financial institutions conducting cryptographic inventory and risk assessment (since July 2025). | Per-domain risk classification (legacy/modern/PQC). Compliance dashboard shows migration progress with CISO-ready metrics. |
Every observed TLS handshake is recorded in an append-only NDJSON file on the agent (/etc/tlslane/events.ndjson). Each line contains:
The log rotates at 100 MB, keeping 9 backups (~1 GB total). Pull event logs from agents via the Compliance or Support page for archival. For real-time forwarding, configure syslog to send events to your SIEM.
The Compliance page provides a CISO-ready view of your organization's PQC readiness:
Forward compliance events in real-time to your SIEM via syslog. Configure on the Settings page or per-agent:
Each event is sent as RFC 5424 with a JSON payload. Facility: authpriv (10), severity: informational (6). TCP uses octet-counted framing (RFC 6587).
When configured via the dashboard Settings page, the syslog URL is pushed to all agents via config poll (within 60 seconds). Agents auto-reconfigure on change and stop forwarding when the URL is cleared.
Export crypto inventory and alerts as NDJSON for batch ingestion:
Both endpoints return application/x-ndjson (one JSON object per line), compatible with Splunk HEC, Elastic Filebeat, and Datadog log ingestion.
TLS Lane provides built-in support channels accessible from the dashboard.
When agents encounter errors, the error count appears as a badge on the Support sidebar link. The Support page lists agents with errors, showing hostname, error count, and status.
For each agent with errors, you can:
After logs are retrieved, click View to open the log viewer. Logs are shown in an editable text area so you can review for personal information (PI/PSI) before submitting.
Only the redacted version is attached to the support ticket — the raw log stays in your account.
Logged-in users can submit support tickets from the Support page. Each ticket includes:
After submission, you can track your tickets and exchange replies with support directly in the dashboard.
The public Contact page is for general inquiries, enterprise deployments, partnerships, and compliance consulting. No account required.
TLS Lane is designed for minimal overhead. Run tlslane bench on your own hardware to measure actual performance.
Measured on AMD Ryzen 9, 100–500 connections, 64 KB data per connection, loopback:
| Mode | Throughput | Latency | CPU / conn | CPU util |
|---|---|---|---|---|
| Direct TCP (baseline) | 234 MB/s | 0.27 ms | 0.30 ms | 113% |
| Proxy monitor | 91 MB/s | 0.69 ms | 0.66 ms | 96% |
| eBPF inline monitor | Zero overhead — kernel-space passive capture, no proxy | |||
Proxy monitor adds +0.42 ms latency per connection. On a real network with 5–50 ms RTT, this is negligible (<1% of round-trip time).
| Metric | Measured |
|---|---|
| New connections/sec | ~500/sec (proxy mode, single core) |
| Concurrent connections | 1,000+ tested with no fd or memory leaks |
| Memory per connection | ~100 bytes (session metadata only) |
| Binary size | ~5 MB (static OpenSSL + Boost) |
| Approach | How it works | Trade-offs |
|---|---|---|
| eBPF inline (tlslane default) | Kernel-space TC classifier reads packets directly off the NIC. No proxy, no TCP termination. | Zero overhead for monitoring. Linux 5.8+ only. Cannot modify traffic (monitor only). |
| Userspace proxy (tlslane proxy) | boost::asio TCP relay on localhost. iptables redirects traffic through the proxy. | Sub-millisecond overhead. Can splice (modify) TLS. Works on any kernel. |
| Hardware appliance | Dedicated hardware with ASIC for TLS acceleration. Sits inline on the network. | Lowest latency for inspection. Expensive. Fixed capacity. No PQC upgrade. |
| Cloud proxy | Traffic routes through a cloud service for inspection. | No on-prem hardware. Adds network hop latency (5–30 ms). Data leaves your network. |
TLS Lane is designed with privacy as a default:
| Command | Description |
|---|---|
sudo tlslane | Monitor mode (passive, no traffic modification) |
sudo tlslane --proxy | Monitor mode, proxy fallback (for non-Linux or old kernels) |
sudo tlslane splice | Splice all traffic |
tlslane splice DOMAIN... | Splice specific domains only |
tlslane splice --exclude DOMAIN... | Splice all except listed domains |
tlslane splice --cert PEM --key PEM | Use your own cert for inbound splice |
sudo tlslane ca generate | Generate root CA |
sudo tlslane ca trust | Install CA to system trust store |
sudo tlslane ca untrust | Remove CA from trust store |
sudo tlslane ca remove | Delete CA file |
tlslane ca show | Print CA certificate PEM |
sudo tlslane update | Download and install latest version |
sudo tlslane update --rollback | Restore previous version |
tlslane --version | Show version |
tlslane --help | Show usage |
tlslane --token TOKEN | Set agent token |
tlslane --management URL | Set management server URL |
tlslane --syslog URL | Forward events to syslog (udp://host:514 or tcp://host:514) |
tlslane --metrics-port N | Enable Prometheus /metrics endpoint on port N |