How we test TLS and HTTPS: handshakes per second with inspection switched on

The datasheet of a firewall or a load balancer states "TLS throughput". The footnote, when there is one, says TLS 1.2, RSA 2048, one cipher, 64 KB objects, inspection off. Your users bring TLS 1.3, ECDSA, 20 KB pages and 50 requests per visit, and your security policy has inspection on. The two numbers differ by a factor of 3 to 5. We measure the second one.

The bench

The device under test is anything that terminates, proxies or inspects TLS: an NGFW, a load balancer, a WAF, a reverse proxy, a VPN concentrator. The generator emulates clients on one side and servers on the other, with real TLS stacks, real certificates and application traffic inside: HTTP/1.1 and HTTP/2 pages, API calls, video, whatever your mix is. Ports from 1G to 100G, L4-7 load at 200 Gbit/s and more when a cluster is under test.

Inspection is configured the way you run it: your decryption policy, your certificate, the categories you exclude. A test with inspection off is a test of a different product.

What we check

• Handshakes per second: full handshakes and resumptions, TLS 1.2 and 1.3, RSA and ECDSA certificates, with the ramp until the first error
• Concurrent sessions: 100,000, 1M and more open TLS sessions with slow traffic inside, memory per session, and the ramp until the first refused connection
• Throughput per cipher suite: AES-GCM, ChaCha20, the key sizes you allow, with the object sizes of your traffic rather than 64 KB
• Inspection on: the same 3 measurements with decryption, IPS and application control active, which is the number you will actually get
• Certificates: chains of 3 and 4, OCSP and CRL checks, expired and revoked certificates and what the box does with them, client certificates where used
• Protocol edge cases: SNI and ESNI handling, ALPN, session tickets, 0-RTT in TLS 1.3, renegotiation, large handshakes with many extensions
• Latency: time to first byte with and without inspection, per percentile
• HA and soak: failover with 1M sessions open, then 24 hours at 80% of the measured handshake rate

The methodology follows RFC 9411 for the security device items, with the traffic mix taken from your own profile.

What usually breaks

The inspection number. An NGFW with 10 Gbit/s on the datasheet gives 9 with TLS off and 2.5 with decryption, IPS and application control on, which is what the customer has paid for. Nobody tested the third configuration before the purchase.

Second case: handshakes with ECDSA. The box has an RSA offload chip and does ECDSA in software, so 20,000 handshakes per second become 3,000 the day the certificate is renewed with a different key type. Found by changing one certificate on the bench.

The third is concurrent sessions. 2M on the datasheet, measured with sessions that carry nothing. With 20 KB pages inside, memory per session grows and the box refuses new connections at 600,000. The number that matters for sizing is the one with traffic inside.

What is in the report

Handshakes, sessions and throughput as tables per protocol version, cipher and certificate type, each in 2 columns: inspection off and inspection on. Latency per percentile. The certificate checks as a pass and fail list. Resources over the run, the device configuration and the traffic profile. The vendor gets enough to repeat each line, and you get a sizing figure you can plan with.

Where to start

Send us the device model, the firmware you plan to run and the topology it will sit in. We answer with a test plan: the items, the bench layout and the dates. The plan is free, the report is yours to keep and to show to the vendor. Write to us or look at what else the bench does.