sslscan: TLS configuration scanning without OpenSSL version lock-in

What sslscan actually enumerates on a TLS endpoint

sslscan connects to an SSL/TLS-enabled service and reports which cipher suites the server accepts, which protocols it negotiates, and which key exchange groups and signature algorithms it advertises. The README lists enumeration of server key exchange groups and server signature algorithms among the version 2 changes, alongside support for new post-quantum groups.

The audience is narrow and practical. Anyone writing a check that has to run from a shell, from a container, or from a build pipeline wants a binary that returns text or XML and exits. sslscan is that shape: one C file at the top level, sslscan.c, a Makefile, and a man page, sslscan.1. There is no daemon, no database, no web UI. The repository also carries a Dockerfile and a docker_test directory, so the project ships its own containerised test path.

The output is opinionated rather than neutral. The fork's changes include highlighting SSLv2 and SSLv3 ciphers, CBC ciphers on SSLv3 for POODLE, 3DES and RC4, NULL and weak ciphers, and anonymous ADH and AECDH ciphers. PFS+GCM suites are marked as good. That colouring is a judgement baked into the tool, which is convenient for a human reading a terminal and awkward if you are parsing the human-readable output rather than the XML.

Why the backend rewrite matters more than the flag list

Version 1 of sslscan leaned on the OpenSSL library it was linked against to decide what it could test. Version 2 rewrote the backend scanning code so the tool is no longer reliant on that OpenSSL version for many checks. The README states this is what allows SSLv2 and SSLv3 support as well as TLSv1.3 regardless of the OpenSSL version sslscan was compiled against. Most of that rewrite is credited to jtesta.

The trade-off is visible in the build system. The README says the minimum OpenSSL version required is 3.5.0 (LTS) as of sslscan 2.2.0, and that if your distribution ships something older, building against it will not work. You then have to do a static build. The Makefile implements this through a STATIC_BUILD variable that points the include and library paths at a local openssl directory and links libssl.a and libcrypto rather than the shared objects. The README is candid that the result is a heavier binary in file size and memory consumption, and that this is the price of checks such as TLS compression.

One deliberate gap: SSLv2 and SSLv3 protocol support is scanned, but individual ciphers are not. If you need per-cipher detail on those two protocols, sslscan will not give it to you.

Installing sslscan and running a first scan

The README recommends ignoring the system OpenSSL and building statically against your own copy. On Debian, the build dependencies are installed first:

apt install git zlib1g-dev make gcc

Then the static target clones the OpenSSL repository and configures, compiles and tests it before compiling sslscan itself:

make static

To build with clang instead, install clang in place of gcc and pass the compiler through:

make static CC=clang

The README gives a way to confirm the result: run sslscan --version and check whether the version string carries a -static suffix. If it does, you are linked against the statically built OpenSSL and the extra checks are available.

There is also a Docker path. The image is built with a make target or directly:

docker build -t sslscan:sslscan .

and then invoked by passing arguments to the entrypoint:

docker run --rm -ti sslscan:sslscan --help

The Dockerfile is worth reading before you deploy it. It builds on alpine, runs make static, strips the binary, and copies it into a scratch image along with libz and the musl loader. The final container runs as USER 65535:65535 and sets ENTRYPOINT to /sslscan, so there is no shell inside and no root process. For a first real scan, pass a hostname and port and read the cipher list, then add --show-certificate if you need the certificate, since certificate information is hidden by default and rejected ciphers only appear with --failed.

The XML schema is the part most likely to break your pipeline

If you are wiring sslscan into anything automated, the XML output is the interface you actually depend on, and the README flags a breaking change in 2.0.0-beta4. Previously multiple certificate elements could appear, one by default and a second when --show-certificate was used. Now there is a parent certificates element wrapping the certificate elements, and each certificate carries a type attribute of either short or full.

Two further details matter for a parser. Servers with multiple certificates using different signature algorithms may return more than one certificate of the same type, so a parser that assumes a single short certificate will silently drop data. And the signature-algorithm element no longer carries the "Signature Algorithm:" prefix or the surrounding spacing and newline, which means any string matching against that prefix needs to change.

The README states plainly that if you use the XML output you may need to make changes to your parser. That is the honest framing: the schema moved, and the project did not promise stability across it. If your tooling treats sslscan XML as a fixed contract, pin the version and test the upgrade rather than tracking the master branch.

Where sslscan is the wrong tool

The Windows story is the clearest limitation. sslscan was written for Linux and, in the README's words, has not been extensively tested on Windows, so the Windows version should be considered experimental. It can be compiled natively or cross-compiled from Linux using the INSTALL file and Makefile.mingw, and pre-built cross-compiled binaries are published on the releases page. If your environment is Windows-first and you need something the vendor supports, this is not it.

macOS is worse. The README describes experimental support for static building on macOS and calls it unsupported, with the caveat that you may need to install whatever dependencies are required to compile OpenSSL from source. Combined with the OpenSSL 3.5.0 floor, that means macOS users are doing a full source build to get a working binary.

There is also a removal to be aware of if you have old scripts: the --http option was dropped because the README says it was broken and had very little use. Any automation still passing that flag will fail outright rather than degrade. And the colour-coded severity in the default output is a human aid, not a machine-readable verdict; if you need a pass/fail decision in code, take it from the XML and encode the policy yourself.

sslscan against testssl.sh and sslyze

The most common comparison is with testssl.sh, a shell-based scanner that also enumerates protocols and ciphers and is known for a broad set of checks in one run. The difference in approach is the dependency chain. testssl.sh is a script, so it depends on a shell environment and the tools it calls. sslscan compiles to a single C binary that can be dropped into a scratch container with no shell at all, which is what the project's own Dockerfile does.

The other comparison is sslyze, a Python tool. That gives you a library as well as a CLI, so you can call it from Python and get structured objects instead of parsing text or XML. sslscan gives you neither: there is no Python binding in this repository, and the interface is the binary plus its output formats. If your workflow is Python, sslyze fits more naturally. If your workflow is a minimal container that runs one process, sslscan fits better.

A note on naming: the repository is rbsec/sslscan and the README opens with the heading sslscan2, because version 2 is the rewrite. The original sslscan.c came from ioerror's fork, which itself existed to add STARTTLS support, and the original README is still included below the current one.

Licence and the cost of keeping up

sslscan is GPL-3.0. That matters if you intend to link it into a proprietary product or ship a modified binary without source; the licence terms govern redistribution, and this is a description of the licence identifier rather than legal advice. Running the binary as a separate process and consuming its XML is a different situation from incorporating sslscan.c into your own codebase, and the distinction is worth raising with whoever handles licensing at your organisation before you build on it.

The upgrade cost is dominated by two things. First, the OpenSSL floor: as of 2.2.0 you need 3.5.0 or newer, so a distribution upgrade that moves OpenSSL can break a dynamic build, and the fallback is the static path with its larger binary and longer build. Second, the XML schema change described above, which is the kind of break that shows up as missing fields rather than a crash. The last push to the repository was on 2026-09-17, and release 2.2.3 is dated the same day, so the project is being worked on; that does not change the fact that the schema has moved once already and may move again.

Editorial conclusion

Adopt sslscan when you need a scriptable, single-binary TLS enumeration pass whose results do not shift with the system OpenSSL version, and when XML output can be consumed by a parser you control. Do not adopt it if you need a maintained Windows toolchain: the README calls the Windows build experimental and points to cross-compiled binaries on the releases page. Do not adopt it if you need a stable XML schema, because the 2.0.0-beta4 change introduced a parent element and a type attribute on certificate elements. Verify first that your distro ships OpenSSL 3.5.0 or newer, otherwise plan for make static, and confirm the -static suffix appears in sslscan --version before trusting that legacy protocol checks are available.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. rbsec/sslscan on GitHub
4. README
5. Releases