CLI Over HTTPS Part 1: The Protocol Tax

brett@network-notes.com (Brett Lykins) — Tue, 28 Apr 2026 09:00:00 +0000

During my six years at Rackspace, we spent a lot of time thinking about how to interact with network devices faster. We had tens of thousands of them; firewalls, load balancers, switches, routers and more, all spread across multiple data centers on four continents.

In the early days, managing devices across these data centers meant running shell scripts, Expect, or Perl from local machines and centralized bastions over the WAN. It was operationally painful. SSH connections to devices on other continents were slow enough that teams scheduled automation runs around maintenance windows not just because of the change itself, but because of how long it took to deliver the changes.

An Erlang-based platform solved this by co-locating the SSH connections with the devices. They ran inside each data center, talking SSH to devices over local links where the protocol overhead was negligible. Phil Toland presented the Erlang architecture at Erlang Factory 2012, detailing Erlang and Ruby managing backups and automation for 20,000+ network devices across 8 data centers. My team later supplemented it with a Go microservices architecture to provide API-driven access to device CLIs. Both systems were effective not just because of language capabilities; crucially they were fast because SSH stayed local.

But, even with co-located endpoints, the Cisco ASA fleet was a special case which tested our capabilities due to the extreme size of some of the Access Lists. That’s when someone discovered that the ASA has an HTTP interface we could use. Not the ineffective ASA Java-based REST API, but an actual CLI-over-HTTPS endpoint used by the ASDM client. There was a URL on the device where you could send the same commands you’d type into an SSH session, but over an HTTPS request. We tried it as an experiment, and it was remarkably faster. What started as a curiosity became a production lifesaver for our ASA fleet.

I’ve been thinking about that experience ever since, and I finally decided to quantify it properly. In this series of posts, I will quantify the performance difference between SSH and HTTPS as CLI transports and explain why the gap exists.

The SSH Tax

For a deeper look at SSH’s protocol layers, channel types, and how NETCONF and RESTCONF fit in, see What Actually Happens When You SSH Into a Router.

When your automation tool opens an SSH connection to a network device, here’s what actually happens on the wire before a single byte of command output comes back. (Throughout this series, “RT” means a round trip: one message out, one message back. “RTT” is the round-trip time in milliseconds for a given network path.)

1. TCP three-way handshake. SYN, SYN-ACK, ACK. One round trip. (The ACK can piggyback on the first data segment, but the connection isn’t usable until the handshake completes.)

2. Protocol version exchange. Client and server each send an identification string (SSH-2.0-OpenSSH_9.6). Another round trip.

3. Key exchange. The client and server negotiate algorithms (encryption, MAC, compression) via KEXINIT, then perform a Diffie-Hellman key exchange. This takes 1-3 round trips depending on whether the KEXINIT messages cross in flight and which DH group is negotiated.

4. Service request. The client requests the ssh-userauth service. One round trip.

5. User authentication. Password or public key auth. 1-3 round trips depending on how many methods the server probes (GSSAPI, publickey, then password, each one a round trip).

6. Channel open. SSH multiplexes channels over a single connection. Opening a session channel is another round trip.

That’s 6-10 round trips just to get an authenticated channel. If you’re running a single exec-style command, add one more round trip for the request/response and you’re done.

But automation tools don’t use exec mode. Netmiko, Ansible, and Scrapli open a PTY/shell channel, which adds:

7. PTY request. Ask the server for a pseudo-terminal. One round trip.

8. Shell request. Start an interactive shell on that PTY. One round trip.

9. Session prep. Send terminal length 0, terminal width 511, and wait for each prompt. Two to three more round trips.

Add it up: 10-15 round trips before you see the output of show version, with most real-world automation sessions landing at 10-12. The SSH3 project cites similar overhead in their motivation for building SSH over HTTP/3.

SSH multiplexing (ControlMaster) amortizes the connection setup cost across sessions, but the first connection still pays the full overhead. It helps for repeated connections to the same device, but doesn’t solve the problem at scale across thousands of hosts.

At zero latency (localhost), nobody cares. At real-world distances, it compounds fast.

What This Costs at Real Distances

Verizon Enterprise publishes monthly backbone latency measurements from their global network. Here’s what SSH connection setup costs at those measured round-trip times, assuming 10-15 round trips for a typical PTY/shell automation session:

Path	Measured RTT	SSH setup (10-15 RT)	Source
US backbone (intra-region)	30ms	300-450ms	Verizon Mar 2026: 29.9ms
Transatlantic (NYC ↔ London)	70ms	700-1,050ms	Verizon Mar 2026: 70.2ms
US ↔ Hong Kong	146ms	1,460-2,190ms	Verizon Mar 2026: 145.5ms
US ↔ New Zealand	174ms	1,740-2,610ms	Verizon Mar 2026: 174.2ms

That’s just connection setup. You haven’t sent a command yet. And if your automation opens a fresh SSH connection per device, or per task, which is Ansible’s default behavior without ControlMaster, you pay this cost repeatedly.

A thousand devices at 30ms RTT without concurrency: 300-450 seconds of pure SSH handshake overhead. At 150ms RTT: 1,500-2,250 seconds. Concurrency reduces wall time, but every device still pays the full per-connection cost.

The Screen-Scraping Tax

SSH’s round-trip overhead is only half the story. The other half is what happens after you connect.

SSH gives you a byte stream. A pseudo-terminal. Your automation tool has to:

Detect the prompt to know when command output is complete. Netmiko does this with regex matching on every chunk of bytes received, waiting for a pattern like hostname#. If the output is large or arrives in small TCP segments, this means multiple read cycles.
Handle pagination. --More-- prompts. Most tools send terminal length 0 first, which is another command round trip.
Navigate mode transitions. enable, configure terminal, interface GigabitEthernet0/0. Each one is a command, a prompt change, and a round trip.
Wait for command completion. Netmiko’s default read_timeout adds deliberate delays to avoid reading partial output.

None of this is Netmiko’s fault. It’s doing the best it can with what SSH gives it: an unstructured byte stream with no framing, no content-length, no end-of-message delimiter. The tool has to infer when the device is done talking. Compare that to HTTPS (Content-Length), NETCONF (]]>]]> delimiter), or even SSH exec mode (exit codes). PTY is the only mode where the client has to guess when the response is complete.

The HTTPS Alternative

Now consider what happens when you send the same command over HTTPS:

1. TCP three-way handshake. Same as SSH. One round trip.

2. TLS 1.3 handshake. 1 round trip. (TLS 1.2 was 2 round trips; TLS 1.3 cut it in half. With session resumption, it’s 0 round trips.)

3. HTTP request/response. Send the command, get the output. 1 round trip.

Total: about 3 round trips for a fresh connection. With connection reuse (HTTP keep-alive, which every HTTP client library does by default): 1 round trip per command after the first.

Side by side, the difference is stark. Here’s the same operation (5 commands at 30ms RTT) over both protocols:

And here’s the part that changes the math entirely: you can batch commands. The Cisco ASA HTTP interface accepts multiple commands in a single request, either slash-separated in the URL or newline-delimited in a POST body. Ten commands, one request, one response. That’s 1 round trip for 10 commands, vs SSH where each command requires its own channel-open and exec round trips.

No prompt detection. No pagination handling. No mode transitions. The response body is the command output, with a proper HTTP Content-Length header. Your client knows exactly when the response is complete.

Prior Art: The Cisco ASA HTTP Interface

This isn’t a theoretical proposal. Cisco has shipped an HTTP-based CLI interface on the ASA for years. Their own documentation opens with this:

One way to interface with most network appliances including ASAs is via CLI. An automated tool could Telnet or SSH into a device, authenticate and execute commands, one at a time. This method has a number of drawbacks, however. The tool must maintain the state of the Telnet and SSH connection, and if that connection is broken, the login process has to be repeated. Using CLI, it is only possible to send one command at a time, so administering many firewalls would be time consuming, especially when the firewalls are some latency away from the management station.

Cisco identified the exact problem and shipped a solution. The interface is straightforward:

1
2
3
4
5
6
7
8
9


# Single command
curl -sk -u admin:admin https://asa.example.com/admin/exec/show+version

# Multiple commands in one request
curl -sk -u admin:admin https://asa.example.com/admin/exec/show+version/show+ip+interface+brief

# Bulk config push
curl -sk -u admin:admin -X POST --data-binary @config.txt \
 https://asa.example.com/admin/config

Basic auth over TLS. URL-encoded commands in the path. Newline-delimited commands in a POST body. No SDK, no client library, no special protocol. Just HTTPS.

Aaron Hackney, another principal engineer at Rackspace at the time who was dealing with the same fleet of ASAs, went deep on this interface in a BRKSEC-2031 session at Cisco Live Orlando 2018. The work involved reverse-engineering the ASDM client’s HTTP calls and building Python tooling to script against the same interface. The two-part Cisco community blog series that followed is still one of the best references for anyone looking to automate ASAs over HTTPS instead of SSH.

“Great, but My Switches Don’t Have an HTTPS CLI”

The network automation community has spent a decade building tooling around SSH. Netmiko, Paramiko, Ansible’s network_cli, Nornir, NAPALM. All SSH-based for CLI interaction. That investment is real and valuable. NETCONF and gNMI exist as alternatives, but they require device support for structured data models. A different paradigm entirely. Many organizations have thousands of CLI commands, templates, and playbooks that work. They don’t need a new data model. They need a faster pipe.

And the ASA’s HTTP interface is the exception, not the rule. Most network platforms (IOS, NX-OS, EOS, Junos) don’t expose their CLI over HTTPS. Realistically, that’s not going to change across the industry without a major shift in how vendors think about management plane interfaces. I’m not holding my breath.

But the protocol overhead problem doesn’t go away just because the devices don’t support the better transport natively. So what do you do?

You move the expensive SSH transactions to the edge. Put a lightweight proxy, an API gateway, a microservice, whatever you want to call it, close to the devices it manages. That proxy talks SSH to the devices over a low-latency local network where the round-trip overhead is negligible. Your automation platform talks HTTPS to the proxy over the WAN, where the round-trip savings actually matter.

The pattern looks like this: your centralized automation (Ansible, Nornir, custom tooling) sends an HTTPS request to a proxy co-located with the devices. The proxy opens an SSH session to the device on a 1-2ms local link, executes the commands, and returns the output in the HTTP response. Your automation never touches SSH directly. It gets the speed of HTTPS over the WAN and the compatibility of SSH on the last hop.

This isn’t hypothetical. It’s the architecture behind tools like my NAAS (Netmiko as a Service) application, which wraps Netmiko’s SSH sessions behind a REST API. Deploy a NAAS instance in each region or data center, and your automation talks HTTP to the nearest one. The SSH overhead stays local. The WAN traffic is pure HTTPS.

In Part 2, I’ll detail a dual-protocol device emulator I built in Go that serves the same commands over both SSH and HTTPS, and a benchmark client that measures the difference at realistic latencies. The code is already public if you want to run ahead.

My take: SSH is a fine protocol for interactive terminal sessions. It’s a poor protocol for automation at scale. The round-trip overhead is baked into the protocol design, and no amount of connection pooling or multiplexing fully eliminates it. HTTPS with TLS 1.3 is a strictly better transport for the “send command, get output” pattern that defines CLI automation. The industry should be building toward it.