CryptoLyzer vs SSLyze vs testssl.sh: A Practical Comparison
Which TLS/cryptography analyzer is right for you?
If you need to audit the cryptographic configuration of a server, you have several tools to choose from. Three of the most capable are testssl.sh, SSLyze, and CryptoLyzer. Each has a different philosophy, a different scope, and a different target audience. This post walks through a detailed comparison to help you choose — or decide whether you need more than one.
Numbers in the comparison below were verified against CryptoLyzer 1.3.0, SSLyze 6.3.1, and testssl.sh v3.3dev.
TL;DR Decision Guide
- Use CryptoLyzer if you need more than TLS — SSH, IKE, HTTP headers, DNS — plus JA3/JA4/HASSH fingerprinting and per-finding severity grading, or cipher-suite coverage beyond OpenSSL’s reach: deprecated, prohibited, rarely used, and experimental algorithms.
- Use testssl.sh if you want a zero-dependency single Bash file, the broadest named-vulnerability checklist, and a single overall SSL-Labs-style A–F server grade.
- Use SSLyze if you want a focused TLS-only scanner that checks configuration against Mozilla’s Modern/Intermediate/Old compliance profiles.
Methodology
- Comparison scope: feature availability and depth, not absolute scanner speed benchmarking.
- Sources: project documentation, source trees, and static capability maps for all three tools.
- Counting rule: features were counted as supported only when there was a documented and/or code-level implementation path in the cited version.
- Caveat: development snapshots can change quickly; re-check versioned behavior before using this as a long-term benchmark.
The Tools at a Glance
testssl.sh (testssl.sh) is a battle-hardened Bash script that has been around since 2012. It requires no installation beyond Bash and OpenSSL, runs everywhere Bash runs, and covers TLS/SSL comprehensively. Its single-file design makes it easy to drop into any environment.
SSLyze (SSLyze) is a Python library and CLI focused on TLS scanning at scale. Its clean Python API and built-in Mozilla compliance checking make it a popular choice for CI/CD pipelines and automated scanning of large server fleets. It is purpose-built for TLS — nothing else.
CryptoLyzer (CryptoLyzer) is a Python library and CLI that takes a broader approach: it analyzes not just TLS/SSL, but also SSH, IKE, HTTP security headers, DNS records (DNSSEC, DMARC, SPF, MTA-STS), and generates JA3/JA4/HASSH fingerprints. Its core differentiator is a custom protocol implementation that does not rely on OpenSSL, allowing it to probe cipher suites and algorithms that OpenSSL-based tools cannot reach.
The short version: CryptoLyzer matches testssl.sh and SSLyze on portability and automation, then goes further — its custom stack reaches protocols and algorithms OpenSSL-based tools cannot.
Feature Comparison
| Feature | CryptoLyzer | testssl.sh | SSLyze |
|---|---|---|---|
| Trust store validation | 7 stores | 5 stores | 6 stores |
| Opportunistic TLS (STARTTLS) | 13 protocols | 12 protocols | 8 protocols |
| SSH analysis | ✓ | ✗ | ✗ |
| HTTP security headers | 10 headers | 7 + 2 partial | 1 header |
| DNS records (DNSSEC, DMARC, SPF, …) | ✓ | ✗ | ✗ |
| Cipher-suite probing beyond OpenSSL | comprehensive | ✗ | ✗ |
| GOST cipher suites (via custom impl.) | ✓ | ✗ | ✗ |
| ShangMi (SM2/SM4) cipher suites | ✓ | ✗ | ✗ |
| Extensions | 7 checks | 7 checks | 3 checks |
| Signature algorithm probing | ✓ | ✓ | ✗ |
| Elliptic curves | 58 curves | 40 curves | ✓ |
| Client simulation | 51 clients | 170 clients | ✗ |
| Vulnerabilities | 14 checks | 13 checks | 8 checks |
| DH parameters | comprehensive | partial | ✗ |
| TLS 1.3 draft version detection | drafts 0–28 | drafts 18–28 | ✗ |
| Post-quantum curves (Kyber, ML-KEM) | ✓ | ✓ | ✗ |
| JA3 / JA4 / HASSH fingerprint generation | ✓ | ✗ | ✗ |
| Parallel scanning | ✓ | ✗ | ✓ |
| Python API | ✓ | ✗ | ✓ |
| Native Windows support | ✓ | ✗ | ✓ |
| Overall server grade | ✗ | ✓ (A–F) | ✗ |
| Mozilla compliance check | ✗ | ✗ | ✓ |
| Custom protocol stack (not limited by OpenSSL) | ✓ | ✗ | ✗ |
The pattern is clear: the three tools overlap on core TLS, but only CryptoLyzer reaches past it into SSH, DNS, fingerprinting, and cipher suites OpenSSL cannot offer.
TLS/SSL Analysis: The Common Ground
All three tools perform the core TLS/SSL analysis tasks you would expect: checking supported protocol versions (SSL 2.0 through TLS 1.3), enumerating cipher suites, inspecting certificates, and detecting known vulnerabilities.
Here is that core analysis in practice — CryptoLyzer enumerating the protocol versions badssl.com negotiates:
$ cryptolyze tls versions badssl.com
* Target:
* Scheme: https
* Address: badssl.com
* IP address: 104.154.89.105
* Port: 443
* Protocol Version: n/a
* Protocol Versions:
1. TLS 1.0 (deprecated)
2. TLS 1.1 (deprecated)
3. TLS 1.2
* Alerts Unsupported TLS Version: no
* Inappropriate Version Fallback: no
Where they diverge is in how they do it and how much they cover.
testssl.sh started as a wrapper around OpenSSL commands, but has grown to include its own socket-level testing for many checks — which is why it can test cipher suites that OpenSSL does not natively support via its command line. This hybrid approach gives it broad coverage without requiring you to compile a custom OpenSSL.
SSLyze uses nassl, a custom wrapper around OpenSSL. Its cipher suite coverage is therefore fundamentally limited to what OpenSSL exposes. What SSLyze lacks in breadth, it makes up for in reliability and speed — it is explicitly designed to scan hundreds of thousands of servers daily.
CryptoLyzer takes a different approach: it contains its own implementation of cryptographic protocols (CryptoParser), keeping them as minimal as needed for analysis, backed by a broad algorithm identifier database (CryptoDataHub). This means CryptoLyzer can probe cipher suites that are not supported by any version of OpenSSL, GnuTLS, LibreSSL, or wolfSSL — including rarely used, deprecated, non-standard, or experimental algorithms.
The result: CryptoLyzer recognizes 400+ cipher suites — more than the 372 entries in testssl.sh’s cipher-mapping file, and more than the ~337 listed on ciphersuite.info.
Opportunistic TLS (STARTTLS)
All three tools support STARTTLS — upgrading a plaintext connection to TLS — but differ in which application protocols they cover.
SSLyze supports 8 protocols: FTP, IMAP, LDAP, POP3, PostgreSQL, RDP, SMTP, and XMPP (client and server).
testssl.sh supports 12 protocols: FTP, IMAP, LDAP, LMTP, MySQL, NNTP, POP3, PostgreSQL, Sieve, SMTP, Telnet, and XMPP (client and server). IRC is referenced in the source but is explicitly marked as not yet implemented.
CryptoLyzer supports 13 protocols: FTP, IMAP, LDAP, LMTP, MySQL, NNTP, OpenVPN, POP3, PostgreSQL, RDP, Sieve, SMTP, and XMPP (client and server).
CryptoLyzer and testssl.sh differ in coverage: CryptoLyzer supports OpenVPN and RDP, while testssl.sh supports Telnet (tn3270).
For opportunistic-TLS coverage, CryptoLyzer spans the widest protocol set, testssl.sh follows closely, and SSLyze is the narrowest.
GOST Cipher Suites: Custom Implementation Matters
GOST (national cryptographic standards of the Russian Federation and CIS countries) cipher suites are a niche but real requirement for auditors working with government or financial infrastructure in those regions.
testssl.sh and SSLyze both rely on OpenSSL for the TLS handshake, and standard OpenSSL builds do not include GOST support. Since a server can only select a cipher suite the client offered, and neither tool can offer GOST suites in its ClientHello, GOST support is effectively undetectable by both — regardless of whether the cipher suite codes appear in their internal mapping.
CryptoLyzer’s custom protocol implementation does not depend on OpenSSL’s GOST support. It can actively probe a server for GOST cipher suite negotiation independently of the underlying TLS library. The same applies to ShangMi (SM2/SM4) cipher suites — the Chinese national cryptographic standards. Like GOST, SM cipher suites are absent from standard OpenSSL builds; CryptoLyzer can negotiate them in the ClientHello and detect SM cipher suite support regardless of what the underlying TLS library exposes.
If GOST or ShangMi detection is in scope, CryptoLyzer is the only tool here that can do it — the OpenSSL-based tools cannot offer these suites at all.
TLS 1.3 Draft Version Detection
Some servers — particularly older or embedded implementations — still negotiate pre-RFC TLS 1.3 draft versions rather than the final 0x0304. Detecting which draft a server supports matters for auditing legacy infrastructure and compatibility analysis.
testssl.sh actively probes for drafts 18–28 (0x7f12–0x7f1c) using its own socket-level implementation. It handles the draft 23 boundary separately, since the extension number for key_share changed between draft 22 and draft 23.
CryptoLyzer probes all known TLS 1.3 draft versions: drafts 0–28 (0x7f00–0x7f1c), plus the three Google experiment versions (0x7e01–0x7e03). It offers the remaining unchecked versions iteratively in the supported_versions extension of each ClientHello, narrowing down until the server’s selection is identified.
SSLyze has no TLS 1.3 draft detection.
For auditing pre-RFC TLS 1.3 stacks, CryptoLyzer covers the widest draft range, testssl.sh the common ones, and SSLyze none.
DH Parameters
All three tools report the DH key size when a DHE cipher suite is negotiated, but the depth of analysis differs significantly.
SSLyze captures the DH parameter size and uses it only to verify Mozilla compliance thresholds. It does not identify the group, check its mathematical properties, or detect key reuse.
testssl.sh identifies well-known DH groups by name — including MODP groups from RFC 3526 and RFC 5114, and FFDHE groups from RFC 7919 — and reports whether the server supports RFC 7919 negotiation via the supported_groups extension. It does not check whether the public parameter is a safe prime, and it does not detect DH key reuse across connections.
CryptoLyzer performs the most complete DH analysis of the three:
- Safe prime check: verifies whether the DH public parameter is a safe prime
- Well-known group identification: matches the parameter against RFC-defined groups (FFDHE, MODP) and application server builtin parameters
- RFC 7919 support: detects whether the server supports FFDHE negotiation via the
supported_groupsextension - Key reuse detection: makes multiple connections and compares the DH public values to determine whether the server is reusing ephemeral keys (non-ephemeral behavior)
For a real DH audit, only CryptoLyzer answers the questions past raw key size — safe prime, known group, and key reuse.
Extensions
TLS extensions provide critical security features beyond the basic handshake. All three tools check some of them, but SSLyze covers fewer than the others.
CryptoLyzer and testssl.sh both check all seven of the following:
- ALPN: which application-layer protocols the server negotiates (HTTP/2, gRPC, etc.)
- Encrypt-then-MAC: whether the server supports the safer MAC ordering defined in RFC 7366
- Extended Master Secret: whether the server supports the session hash binding from RFC 7627, mandatory per RFC 9325
- NPN: the deprecated predecessor to ALPN (Next Protocol Negotiation)
- Renegotiation Indication: whether the server supports secure renegotiation (RFC 5746)
- Session Ticket: whether the server supports stateless session resumption via tickets
- Clock accuracy: whether the server’s internal clock (from the
gmt_unix_timefield in the ServerHello random) is accurate
SSLyze checks only three: Extended Master Secret, Renegotiation Indication, and Session Ticket. It does not check ALPN, Encrypt-then-MAC, NPN, or clock accuracy.
CryptoLyzer and testssl.sh give full extension visibility; SSLyze sees only the three resumption- and renegotiation-related ones.
Signature Algorithms
The signature_algorithms TLS extension controls which signature algorithm and hash combinations the client is willing to accept from the server. Probing which combinations the server actually supports — rather than just reading what the certificate uses — reveals the server’s true capability.
CryptoLyzer has a dedicated sigalgos analyzer that probes signature algorithm support directly via the TLS handshake. It tests RSA, ECDSA, DSS, and GOST authentication types, offering each algorithm individually and recording which ones the server accepts.
testssl.sh tests 36 predefined signature algorithm combinations covering RSA, DSA, ECDSA, RSA-PSS, EdDSA, SM2, and post-quantum ML-DSA variants. It reports results separately for TLS 1.2 and TLS 1.3, and assigns severity ratings — critical for MD5, high for SHA-1.
SSLyze has no dedicated signature algorithm prober. Its certificate analysis extracts the algorithm used in the leaf certificate, but it does not probe which algorithms the server would accept at the TLS handshake level.
To learn the server’s true signature-algorithm capability, use CryptoLyzer or testssl.sh; SSLyze reports only what the certificate already reveals.
Elliptic Curves
All three tools enumerate which elliptic curves (named groups) a server supports, but they differ in coverage and how results are presented.
CryptoLyzer probes curves from CryptoDataHub’s database of 58 TLS named curves. It also detects whether the server supports the supported_groups extension itself, and reports which curve was selected in TLS 1.3 key share negotiation.
testssl.sh tests 40 curves, including all standard NIST and Brainpool curves, Bernstein curves (X25519, X448), their TLS 1.3 Brainpool variants, and post-quantum hybrid groups (MLKEM512, MLKEM768, MLKEM1024, X25519MLKEM768, SecP256r1MLKEM768, X25519Kyber768Draft00, SecP384r1MLKEM1024). It flags curves deprecated by RFC 8446 and integrates curve support into its client simulation output.
SSLyze has a dedicated ELLIPTIC_CURVES scan command that tests each curve supported by the underlying OpenSSL build. It reports both accepted and rejected curves, making it straightforward to see exactly which curves the server declines.
All three enumerate curves, but CryptoLyzer probes the widest set, testssl.sh is close behind, and SSLyze is bounded by what its OpenSSL build exposes.
Client Simulation
Client simulation tests what a specific real-world client — a browser, email client, or application — would actually negotiate when connecting to the server. This is more actionable than raw capability enumeration: it answers “would Chrome 100 succeed, and with which cipher suite?”
CryptoLyzer simulates 51 web browser versions — 19 Chromium, 25 Firefox, and 7 Opera — and records the full set of negotiated parameters for each: protocol version, cipher suite, compression method, application protocol (ALPN/NPN), named group, and whether ECDH or DH key exchange was used. It currently covers HTTPS only.
testssl.sh simulates 170 clients defined as raw ClientHello byte sequences. Coverage spans Android browsers (version 2.3.7 through 13), desktop browsers (Chrome, Firefox, Edge, Safari, Internet Explorer, Opera), legacy clients (SSLeay, older OpenSSL), and post-quantum-capable clients. For each client, testssl.sh records whether the handshake succeeded and which parameters were negotiated, including minimum and maximum key size constraints per algorithm.
SSLyze has no client simulation capability.
testssl.sh simulates the most client profiles, CryptoLyzer records the deepest per-client negotiation detail, and SSLyze does not simulate clients at all.
Vulnerabilities
All three tools detect configuration weaknesses, but differ in which specific vulnerabilities they check for.
| Vulnerability | CryptoLyzer | testssl.sh | SSLyze |
|---|---|---|---|
| D(HE)at attack | ✓ | ✗ | ✗ |
| DROWN attack | ✓ | ✓ | ✗ |
| FREAK attack | ✓ | ✓ | ✗ |
| Logjam attack | ✓ | ✓ | ✗ |
| Lucky Thirteen attack | ✓ | ✓ | ✗ |
| Sweet32 attack | ✓ | ✓ | ✗ |
| RC4 ciphers | ✓ | ✓ | ✓ |
| Anonymous Diffie-Hellman ciphers | ✓ | ✓ | ✓ |
| Null encryption ciphers | ✓ | ✓ | ✓ |
| Export grade ciphers | ✓ | ✓ | ✓ |
| Non-forward-secret ciphers | ✓ | ✓ | ✓ |
| Inappropriate version fallback | ✓ | ✓ | ✓ |
| Early TLS versions | ✓ | ✓ | ✓ |
| Insecure SSL versions | ✓ | ✓ | ✓ |
testssl.sh has the broadest vulnerability coverage of any TLS-only tool. Beyond the checks listed above, it also tests for Heartbleed, BEAST, POODLE (SSL and TLS), CCS Injection, Ticketbleed, ROBOT, and CRIME/BREACH — 21+ named checks in total.
CryptoLyzer covers all 14 checks listed above. It is the only tool that detects the D(HE)at attack, a denial-of-service vulnerability targeting servers that accept large DH key exchange parameters. Logjam is covered by its weak DH detection, which flags DH parameters with key size ≤ 1024 bits.
Pointed at one of the deliberately weak badssl.com endpoints, CryptoLyzer surfaces the relevant findings directly — the CLI colors each result green, yellow, or red by severity:
$ cryptolyze tls vulns rc4.badssl.com
* Target:
* Scheme: https
* Address: rc4.badssl.com
* IP address: 104.154.89.105
* Port: 443
* Protocol Version: n/a
* Cipher Suites:
* Sweet32: no
* Anonymous Diffie-Hellman: no
* RC4: yes
* non-forward secret: yes (deprecated)
* NULL encryption: no
* Lucky Thirteen attack: no
* FREAK: no
* Logjam: no
* export-grade: no
* Diffie-Hellman Parameters:
* D(HE)at attack: no
* weak DH: no
* Protocol Versions:
* Inappropriate Version Fallback: no
* DROWN: no
* Early TLS version: yes (deprecated)
* SSL version: no
Here RC4 and an early TLS version are flagged on rc4.badssl.com; running the same check against dh1024.badssl.com instead flags weak DH and the Lucky Thirteen attack.
SSLyze takes a different approach: it checks for Heartbleed, CCS Injection, ROBOT, and inappropriate version fallback as dedicated vulnerability scans. For cipher-related weaknesses (RC4, null encryption, anonymous DH, export grade, non-forward-secret), SSLyze enumerates cipher suites per protocol version — these appear in its output but are not flagged as named vulnerabilities. It does not check for DROWN, FREAK, Sweet32, Lucky Thirteen, Logjam, or D(HE)at.
testssl.sh has the broadest named-vulnerability list, CryptoLyzer is the only tool flagging D(HE)at, and SSLyze names the fewest.
Grading and Compliance
The three tools take fundamentally different approaches to summarizing a server’s security posture.
testssl.sh implements an SSL Labs-compatible letter grading system. It computes a numeric score from 0–100 across three weighted categories — protocol support (30%), key exchange strength (30%), and cipher strength (40%) — then maps the score to a letter grade: A+ or A for 80 and above, B for 65–79, C for 50–64, D for 35–49, E for 20–34, and F below that. The grade can be capped downward by detected vulnerabilities (Heartbleed, DROWN, FREAK, LOGJAM, and others) and by certificate problems such as expiry or chain errors. The methodology follows the SSL Labs Server Rating Guide.
SSLyze takes a compliance-based approach rather than a graded one. It checks the server configuration against Mozilla’s three TLS configuration profiles — Modern, Intermediate, and Old — and produces a pass/fail result per profile with a specific list of violations. This is useful for enforcing configuration standards in a CI/CD pipeline but does not produce a score or ranking.
CryptoLyzer does not produce an overall server grade or compliance verdict. Instead, it assigns a severity grade (SECURE, DEPRECATED, WEAK, or INSECURE) to each individual finding throughout its output. The color-coded CLI reflects this: algorithm names and key sizes are shown in green, yellow, or red depending on their current security strength. This gives per-finding context rather than a single summary number.
Choose by the summary you need: a letter grade from testssl.sh, a compliance pass/fail from SSLyze, or per-finding severity from CryptoLyzer.
Public Keys (Certificates)
All three tools analyze the server’s X.509 certificate chain. The differences lie in how deeply each tool inspects trust, revocation, extensions, and transparency.
Trust Store Validation
Each tool validates the certificate chain against platform-specific root CA trust stores. A certificate trusted by Mozilla may not be trusted by Apple or Microsoft — checking multiple stores catches mismatches that single-store validation misses.
| Trust Store | CryptoLyzer | testssl.sh | SSLyze |
|---|---|---|---|
| Apple | ✓ | ✓ | ✓ |
| ✓ | ✗ | ✓ | |
| Google Chrome | ✓ | ✗ | ✗ |
| Microsoft | ✓ | ✓ | ✓ |
| Mozilla | ✓ | ✓ | ✓ |
| OpenJDK | ✓ | ✗ | ✓ |
| Oracle Java | ✓ | ✓ | ✓ |
CryptoLyzer validates against seven trust stores — Apple, Google (AOSP), Google Chrome, Microsoft, Mozilla, OpenJDK, and Oracle Java — using CryptoDataHub’s built-in root certificate database. It also verifies chain ordering, detects whether the trust anchor is included, and checks subject name matching with and without SNI.
testssl.sh ships with four bundled trust store files (Apple, Microsoft, Mozilla, Oracle Java) plus a Linux distribution bundle. The Linux bundle is a copy of the Mozilla NSS store as packaged by Debian and is effectively a delayed mirror of the Mozilla store. testssl.sh validates against each store independently and reports per-store results.
SSLyze validates against six trust stores — Apple, Google (AOSP), Microsoft, Mozilla, OpenJDK, and Oracle Java — using the trust_stores_observatory package.
Revocation Checking
Certificate revocation — verifying that a certificate has not been withdrawn by its issuer — can be checked via CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol).
| Revocation Check | CryptoLyzer | testssl.sh | SSLyze |
|---|---|---|---|
| CRL distribution points | ✓ | ✓ | ✓ |
| OCSP responders | ✓ | ✓ | ✓ |
| OCSP stapling | ✓ | ✓ | ✓ |
All three tools extract CRL distribution point URLs and OCSP responder URLs from the certificate, detect OCSP stapling in the TLS handshake, and parse the stapled OCSP response.
CryptoLyzer parses the full OCSP response including status (good/revoked/unknown), responder identity, timestamps (produced_at, this_update, next_update), update interval, and — if revoked — the revocation time and reason. It actively fetches OCSP and CRL data to verify revocation status.
testssl.sh checks both OCSP and CRL with the --phone-out option (which contacts external servers). It detects OCSP must-staple and parses stapled OCSP responses.
SSLyze parses stapled OCSP responses and detects the OCSP must-staple extension in the leaf certificate.
Certificate Extensions
| Extension | CryptoLyzer | testssl.sh | SSLyze |
|---|---|---|---|
| TLS features (OCSP must-staple) | ✓ | ✓ | ✓ |
| Extended validation (EV) | ✓ | ✗ | ✓ |
CryptoLyzer extracts TLS feature requirements from the certificate (e.g., OCSP must-staple) and detects extended validation (EV) certificates by matching certificate policy OIDs against known CA-specific EV OIDs.
testssl.sh detects the OCSP must-staple extension but does not identify EV certificates.
SSLyze detects both OCSP must-staple and EV certificates.
Certificate Transparency (CT)
Certificate Transparency is a public logging framework that makes it possible to detect misissued certificates. Servers can provide Signed Certificate Timestamps (SCTs) — cryptographic proofs that a certificate has been submitted to a CT log — via TLS extensions or embedded in the certificate itself.
| CT Feature | CryptoLyzer | testssl.sh | SSLyze |
|---|---|---|---|
| SCT detection | ✓ | ✓ | ✓ |
| Timestamp information | ✓ | ✓ | ✓ |
| CT log identification | ✓ | ✗ | ✗ |
| CT log trust status | ✓ | ✗ | ✗ |
CryptoLyzer extracts SCTs from both the TLS signed_certificate_timestamp extension and the certificate’s embedded SCT extension (OID 1.3.6.1.4.1.11129.2.4.2). For each SCT, it reports the version, timestamp, signature algorithm, and — uniquely — identifies the CT log by matching the log ID against CryptoDataHub’s database of known CT logs (operator, URL, description, maximum merge delay, temporal interval, and current state). CryptoDataHub also tracks CT log trust stores from major browser vendors (Google, Apple), so CryptoLyzer can report not only which log signed an SCT but also whether that log is currently trusted under each vendor’s CT inclusion policy.
testssl.sh detects SCTs and reports timestamp information, but does not resolve log IDs to named CT logs.
SSLyze counts embedded SCTs and reports their presence, but does not provide detailed per-SCT information or log identification.
All three cover the certificate basics; CryptoLyzer goes deepest on trust stores, revocation parsing, and CT-log identification.
HTTP Security Headers
All three tools inspect HTTP response headers to some degree, but their coverage ranges from a single header (SSLyze) to comprehensive analysis (CryptoLyzer).
Security Headers
| Header | CryptoLyzer | testssl.sh | SSLyze |
|---|---|---|---|
| Content-Security-Policy (CSP) | ✓ | partial | ✗ |
| Content-Security-Policy-Report-Only | ✓ | partial | ✗ |
| Expect-CT | ✓ | ✓ | ✗ |
| Expect-Staple | ✓ | ✗ | ✗ |
| HTTP Public Key Pinning (HPKP) | ✓ | ✓ | ✗ |
| Referrer-Policy | ✓ | ✓ | ✗ |
| Strict-Transport-Security (HSTS) | ✓ | ✓ | ✓ |
| X-Content-Type-Options | ✓ | ✓ | ✗ |
| X-Frame-Options | ✓ | ✓ | ✗ |
| X-XSS-Protection | ✓ | ✓ | ✗ |
CryptoLyzer checks all 10 security headers listed above — including Expect-Staple, which neither of the other tools covers.
testssl.sh checks 9 of the 10 headers — 7 fully and 2 (Content-Security-Policy and Content-Security-Policy-Report-Only) with presence detection and raw value reporting only, without parsing individual directives. It does not check Expect-Staple.
SSLyze checks only Strict-Transport-Security (HSTS), parsing its max-age, includeSubDomains, and preload directives.
Some headers in this section are considered legacy under modern browser security models. In particular, Expect-CT, HPKP, and X-XSS-Protection are largely deprecated for mainstream browser hardening, but they can still be relevant in historical audits, internal environments, and non-browser client ecosystems.
Content Security
Beyond headers, CryptoLyzer also analyzes the HTML response body for content security issues that the other tools do not check.
| Check | CryptoLyzer | testssl.sh | SSLyze |
|---|---|---|---|
| Subresource integrity | ✓ | ✗ | ✗ |
| Mixed content | ✓ | ✗ | ✗ |
Subresource integrity (SRI) ensures that resources loaded from third-party CDNs have not been tampered with, by requiring a cryptographic hash in the integrity attribute of <script> and <link> tags. CryptoLyzer detects whether SRI is used for external resources.
Mixed content occurs when an HTTPS page loads resources (scripts, stylesheets, images) over plain HTTP, undermining the confidentiality and integrity guarantees of TLS. CryptoLyzer detects both active mixed content (scripts, iframes) and passive mixed content (images, media).
For HTTP header and content-security auditing, CryptoLyzer is comprehensive, testssl.sh partial, and SSLyze limited to HSTS.
Post-Quantum Cryptography
Both testssl.sh and CryptoLyzer detect post-quantum key exchange. testssl.sh supports detection of X25519Kyber768Draft00, MLKEM512, MLKEM768, MLKEM1024, SecP256r1MLKEM768, SecP384r1MLKEM1024, and X25519MLKEM768 via OpenSSL.
CryptoLyzer’s custom implementation covers a wider set of Kyber and ML-KEM variants, including hybrid combinations — again without being limited to what OpenSSL exposes.
SSLyze does not currently have documented post-quantum curve support.
For PQC detection, CryptoLyzer and testssl.sh both work — CryptoLyzer reaching variants OpenSSL does not expose — while SSLyze has none.
Beyond TLS: SSH, IKE, HTTP Headers, and DNS
testssl.sh and SSLyze are TLS-only tools by design. CryptoLyzer covers additional protocols — SSH, IKE, HTTP security headers, and DNS — making it the only tool in this comparison that can audit the full cryptographic posture of a server from a single interface.
SSH
CryptoLyzer analyzes SSH servers with the same depth it applies to TLS. Its SSH analysis covers:
- Supported cipher suites, MAC algorithms, and key exchange methods
- Host key types, X.509 certificates and chains
- Diffie-Hellman group exchange key sizes
- Vulnerabilities: Terrapin, D(HE)at, Logjam, Sweet32, RC4, anonymous DH, null encryption, early SSH versions
DNS Records
CryptoLyzer is the only tool of the three that analyzes DNS records beyond basic hostname resolution. It covers:
- DNSSEC: DNSKEY, DS, and RRSIG records, including analysis of signing key types and sizes
- Email authentication: DMARC, SPF, MTA-STS, SMTP TLS Reporting (TLSRPT)
- SSH fingerprints (SSHFP): SSHFP DNS records, with cross-verification against retrieved SSH host key fingerprints
This makes CryptoLyzer uniquely useful for end-to-end mail security audits, where the DNS configuration, STARTTLS support, and TLS cipher suites all need to be checked together.
Fingerprinting: CryptoLyzer Only
Neither testssl.sh nor SSLyze provides fingerprinting capabilities. CryptoLyzer is the only tool in this comparison that can fingerprint connecting clients. All fingerprinting capabilities are accessible through the unified fingerprint command.
JA3 (TLS Client Fingerprinting)
CryptoLyzer can act as a TLS server to capture and generate JA3 fingerprints of any connecting TLS client — browsers, email clients, custom applications, VPN clients — regardless of the client type. It supports fingerprinting across 11 application protocols:
- FTP
- LDAP
- LMTP
- MySQL
- NNTP
- OpenVPN
- POP3
- PostgreSQL
- RDP
- Sieve
- SMTP
CryptoLyzer can also decode an existing JA3 tag into a human-readable breakdown of the TLS parameters it encodes — TLS version, cipher suites, extensions, elliptic curves, and point formats — making it useful for threat intelligence and forensic analysis without needing to capture live traffic.
JA4 (TLS Client Fingerprinting)
CryptoLyzer also generates and decodes JA4 fingerprints, the successor to JA3. JA4 produces a structured 36-character tag — a 10-character prefix encoding TLS version, cipher count, extension count, and ALPN, followed by two 12-character truncated SHA-256 hashes of the sorted cipher suites and extensions, separated by underscores. Because JA4 includes signature algorithms and normalizes field ordering before hashing, it produces more stable fingerprints than JA3 across implementation differences, with fewer collisions.
CryptoLyzer also generates JA4X fingerprints for X.509 certificates — a compact tag derived from the certificate’s issuer, subject, and extension OIDs — which allows tracking certificate issuance patterns across different subject names.
For client fingerprinting and tag decoding, CryptoLyzer stands alone in this comparison.
Python API
SSLyze was built API-first. Its Python API is well-documented, supports async scanning, and is widely used in production pipelines.
CryptoLyzer also provides a Python API covering all its protocols — TLS, SSH, HTTP headers, DNS, and fingerprinting. The API is the primary interface; the CLI is built on top of it.
testssl.sh has no Python API. Being a Bash script, it can be invoked as a subprocess and its JSON output parsed, but this is considerably less ergonomic than a native Python library.
For Python-native pipelines, SSLyze and CryptoLyzer both offer real APIs; testssl.sh offers only subprocess-and-parse.
Windows Support
CryptoLyzer and SSLyze both run natively on Windows (pure Python or Python with compiled wheels).
testssl.sh requires a Bash environment on Windows — WSL, Cygwin, or MSYS2 — which adds friction in Windows-native environments.
On Windows-native hosts, CryptoLyzer and SSLyze run directly, while testssl.sh needs a Bash layer.
Output Formats
| Format | CryptoLyzer | testssl.sh | SSLyze |
|---|---|---|---|
| Human-readable (color-coded) | ✓ | ✓ | ✓ |
| JSON | ✓ | ✓ | ✓ |
| Markdown | ✓ | ✗ | ✗ |
| HTML | ✗ | ✓ | ✗ |
| CSV | ✗ | ✓ | ✗ |
CryptoLyzer’s Markdown output is particularly useful for generating documentation directly from audit results — it can be converted to DOCX or PDF, or embedded in reports, without post-processing.
CryptoLyzer’s color-coded CLI output uses a traffic-light system: algorithm names and key sizes are colored green, yellow, or red based on their current security strength.
Parallel Scanning
When scanning multiple targets, the tools differ significantly in concurrency support.
SSLyze was designed from the ground up for fleet scanning. Its Scanner class accepts a list of targets, tests connectivity to all of them in parallel (default: 10 concurrent), then runs the actual TLS scans with up to 10 concurrent targets and 5 threads per target. Results stream back as each target completes.
CryptoLyzer supports parallel scanning via the -j / --parallel flag. Targets are dispatched to a ThreadPoolExecutor and analyzed concurrently up to the specified worker count. Results are printed in the order targets were given on the command line, regardless of completion order.
testssl.sh is primarily sequential. It has a --parallel option, but it parallelizes checks within a single target rather than scanning multiple targets concurrently.
For multi-target scanning, SSLyze and CryptoLyzer parallelize across targets, while testssl.sh parallelizes only within a single target.
When to Use Which Tool
Use testssl.sh when:
- You need a quick, zero-dependency TLS check on any Unix system
- You want a comprehensive single-file tool with broad vulnerability coverage
- Human-readable HTML reports are a requirement
- You do not need a programmable API
Use SSLyze when:
- You need a clean Python API for integration into pipelines
- Mozilla compliance checking is a requirement
- TLS is the only protocol you need to analyze
Use CryptoLyzer when:
- You need to analyze protocols beyond TLS: SSH, IKE, HTTP headers, DNS records
- You need JA3, JA4, or HASSH fingerprinting
- Cipher suite coverage beyond OpenSSL’s limits matters (GOST, experimental, deprecated algorithms)
- You need a Python API that covers all of the above
- You want a single tool for a complete cryptographic posture assessment
Known Limits
- CryptoLyzer does not currently provide a single overall server letter grade.
- CryptoLyzer does not currently provide a built-in Mozilla profile compliance verdict.
- testssl.sh is less ergonomic for Python-native integrations because it is a shell-first tool.
- SSLyze is intentionally TLS-focused and does not target SSH or DNS security analysis.
Packaging
The table below shows package repository availability across major distributions. “AUR” = Arch User Repository (community-maintained). “OBS” = author-maintained OpenSUSE Build Service repository requiring a custom package source. testssl.sh is packaged as testssl (without the .sh suffix) in Fedora’s RPM repositories.
| Distribution | CryptoLyzer | testssl.sh | SSLyze |
|---|---|---|---|
| Debian 12 (bookworm) | ✗ | ✓ | ✗ |
| Debian 13 (trixie) | OBS | ✓ | ✗ |
| Debian sid (unstable) | ✓ | ✓ | ✗ |
| Fedora (all releases) | ✗ | ✓ | ✗ |
| openSUSE Tumbleweed | OBS | ✓ | ✗ |
| Ubuntu 22.04 LTS | ✗ | ✓ | ✗ |
| Ubuntu 24.04 LTS | OBS | ✓ | ✗ |
| Ubuntu 26.04 LTS | OBS | ✓ | ✗ |
| Arch Linux | AUR | ✓ | AUR |
| Kali Linux | ✗ | ✓ | ✓ |
testssl.sh is the most broadly packaged of the three. It appears in every Debian release since Debian 11, all supported Fedora releases, openSUSE Tumbleweed, all Ubuntu LTS releases, Arch Linux’s official extra repository, and Kali Linux.
SSLyze is not packaged in Debian, Fedora, openSUSE, or Ubuntu. It is available in Kali Linux’s official repositories and in the AUR. On other platforms, pip install sslyze is the standard installation method.
CryptoLyzer is in Debian sid (unstable) and available via the author-maintained OBS repository for Debian 13, openSUSE Tumbleweed, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. It is also in the AUR. On all platforms it can be installed via pip install cryptolyzer. None of the compared tools publish author-maintained binary repositories for multiple distributions; CryptoLyzer’s OBS project is the only one that does.
Conclusion
testssl.sh and SSLyze are excellent tools for what they do — TLS/SSL analysis — and each has earned its place in the standard toolkit. If TLS is all you need, either is a fine choice depending on whether you prefer shell scripts or Python libraries.
CryptoLyzer takes a different bet: that a serious cryptographic audit extends beyond TLS, that cipher suite coverage matters at the margins, and that having one tool with a consistent Python API across all protocols is worth the investment.
If your scope is a web server’s HTTPS configuration, any of these three will serve you well. If you need to audit the full cryptographic posture of a server — TLS, SSH, IKE, HTTP headers, and DNS together — CryptoLyzer is the only tool in this comparison that covers all of it.