Clear output: you can tell easily whether anything is good or bad
Ease of installation: It works for Linux, Darwin, FreeBSD and MSYS2/Cygwin out of the box: no need to install or configure something, no gems, CPAN, pip or the like.
Flexibility: You can test any SSL/TLS enabled and STARTTLS service, not only webservers at port 443
Toolbox: Several command line options help you to run YOUR test and configure YOUR output
Reliability: features are tested thoroughly
Verbosity: If a particular check cannot be performed because of a missing capability on your client side, you'll get a warning
Privacy: It's only you who sees the result, not a third party
Freedom: It's 100% open source. You can look at the code, see what's going on and you can change it. Heck, even the development is open (github)
testssl.sh is pretty much portable/compatible. It is working on every Linux, Mac OS X, FreeBSD distribution, on MSYS2/Cygwin (slow).
It is supposed also to work on any other unixoid systems.
A newer OpenSSL version (1.0) is recommended though. /bin/bash is a prerequisite –
otherwise there would be no sockets.
As for security reasons some distributors outphase the dirty stuff you want to check for – it's recommended
to compile OpenSSL (best from github.com/PeterMosmans/openssl)
by yourself or check out the distributed OpenSSL binaries (Linux) – they
come with a whopping 197 ciphers – ~85 more than
on an average Linux distro (note: openssl-1.0.2i-chacha.pm.ipv6.Linux+FreeBSD.tar.gz is a Linux- and FreeBSD-only tarball with IPv6 support. The directory openssl-1.0.2i-chacha.pm.ipv6.contributed/ contains contributed builds for ARM7l and Darwin binaries). In any case: Except the ciphers, you will get a
warning if your OpenSSL client cannot perform a specific check, see below.
Since 2.4 on some of those checks are done with bash sockets – to be improved gradually. 2.9dev has almost every check with bash sockets.
Same applies to LibreSSL: Basically for security reasons it has lots of flawed features (ciphers, protocols and more) disabled –
thus for TLS testing it's not a good choice. testssl.sh will improve over
time as more and more checks are done via bash sockets.
Development takes place at github. This website is
referring to the latest stable version only (2.8) and provides code, binaries and documention for stable. In the development version @ github things might have changed.
As I do releases on github too you can as well pull the zip for a stable release from there.
Command line shortcuts
Note the following features supported by the webserver configuration:
curl -L https://testssl.sh or wget -O - https://testssl.sh pulls the current stable code
curl -L https://testssl.sh/dev/ or wget -O - https://testssl.sh/dev/ pulls the current development code
– each to standard output. Please note however that for 2.9dev you'll miss the mandatory files in etc/ though.
The normal use case is probably just testssl.sh <hostname>, see first picture right hand above (a deliberately
Starting testssl.sh with no params will give you a general idea how to use it:
userid@somehost:~ % testssl.sh
-h, --help what you're looking at
-b, --banner displays banner + version of testssl.sh
-v, --version same as previous
-V, --local pretty print all local ciphers
-V, --local <pattern> which local ciphers with <pattern> are available?
(if pattern not a number: word match)
testssl.sh <options> URI ("testssl.sh URI" does everything except -E)
-e, --each-cipher checks each local cipher remotely
-E, --cipher-per-proto checks those per protocol
-f, --ciphers checks common cipher suites
-p, --protocols checks TLS/SSL protocols (including SPDY/HTTP2)
-y, --spdy, --npn checks for SPDY/NPN
-Y, --http2, --alpn checks for HTTP2/ALPN
-S, --server-defaults displays the server's default picks and certificate info
-P, --server-preference displays the server's picks: protocol+cipher
-x, --single-cipher <pattern> tests matched <pattern> of ciphers
(if <pattern> not a number: word match)
-c, --client-simulation test client simulations, see which client negotiates with cipher and protocol
-H, --header, --headers tests HSTS, HPKP, server/app banner, security headers, cookie, reverse proxy, IPv4 address
-U, --vulnerable tests all vulnerabilities
-B, --heartbleed tests for heartbleed vulnerability
-I, --ccs, --ccs-injection tests for CCS injection vulnerability
-R, --renegotiation tests for renegotiation vulnerabilities
-C, --compression, --crime tests for CRIME vulnerability
-T, --breach tests for BREACH vulnerability
-O, --poodle tests for POODLE (SSL) vulnerability
-Z, --tls-fallback checks TLS_FALLBACK_SCSV mitigation
-F, --freak tests for FREAK vulnerability
-A, --beast tests for BEAST vulnerability
-J, --logjam tests for LOGJAM vulnerability
-D, --drown tests for DROWN vulnerability
-s, --pfs, --fs, --nsa checks (perfect) forward secrecy settings
-4, --rc4, --appelbaum which RC4 ciphers are being offered?
-t, --starttls <protocol> does a default run against a STARTTLS enabled <protocol>
--xmpphost <to_domain> for STARTTLS enabled XMPP it supplies the XML stream to-'' domain -- sometimes needed
--mx <domain/host> tests MX records from high to low priority (STARTTLS, port 25)
--ip <ip> a) tests the supplied <ip> v4 or v6 address instead of resolving host(s) in URI
b) arg "one" means: just test the first DNS returns (useful for multiple IPs)
--file <fname> mass testing option: Reads command lines from <fname>, one line per instance.
Comments via # allowed, EOF signals end of <fname>. Implicitly turns on "--warnings batch"
partly mandatory parameters:
URI host|host:port|URL|URL:port (port 443 is assumed unless otherwise specified)
pattern an ignore case word pattern of cipher hexcode or any other string in the name, kx or bits
protocol is one of the STARTTLS protocols ftp,smtp,pop3,imap,xmpp,telnet,ldap
(for the latter two you need e.g. the supplied openssl)
tuning options (can also be preset via environment variables):
--bugs enables the "-bugs" option of s_client, needed e.g. for some buggy F5s
--assume-http if protocol check fails it assumes HTTP protocol and enforces HTTP checks
--ssl-native fallback to checks with OpenSSL where sockets are normally used
--openssl <PATH> use this openssl binary (default: look in $PATH, $RUN_DIR of testssl.sh)
--proxy <host>:<port> connect via the specified HTTP proxy
-6 use also IPv6. Works only with supporting OpenSSL version and IPv6 connectivity
--sneaky leave less traces in target logs: user agent, referer
output options (can also be preset via environment variables):
--warnings <batch|off|false> "batch" doesn't wait for keypress, "off" or "false" skips connection warning
--quiet don't output the banner. By doing this you acknowledge usage terms normally appearing in the banner
--wide wide output for tests like RC4, BEAST. PFS also with hexcode, kx, strength, RFC name
--show-each for wide outputs: display all ciphers tested -- not only succeeded ones
--mapping <no-rfc> don't display the RFC Cipher Suite Name
--color <0|1|2> 0: no escape or other codes, 1: b/w escape codes, 2: color (default)
--colorblind swap green and blue in the output
--debug <0-6> 1: screen output normal but keeps debug output in /tmp/. 2-6: see "grep -A 5 '^DEBUG=' testssl.sh"
file output options (can also be preset via environment variables):
--log, --logging logs stdout to <NODE-YYYYMMDD-HHMM.log> in current working directory
--logfile <logfile> logs stdout to <file/NODE-YYYYMMDD-HHMM.log> if file is a dir or to specified log file
--json additional output of findings to JSON file <NODE-YYYYMMDD-HHMM.json> in cwd
--jsonfile <jsonfile> additional output to JSON and output JSON to the specified file
--csv additional output of findings to CSV file <NODE-YYYYMMDD-HHMM.csv> in cwd
--csvfile <csvfile> set output to CSV and output CSV to the specified file
--append if <csvfile> or <jsonfile> exists rather append then overwrite
All options requiring a value can also be called with '=' e.g. testssl.sh -t=smtp --wide --openssl=/usr/bin/openssl <URI>.
<URI> is always the last parameter.
Need HTML output? Just pipe through "aha" (ANSI HTML Adapter: github.com/theZiz/aha) like
"testssl.sh <options> <URI> | aha >output.html"
You are free to check any port – supposed there's any SSL enabled service (TCP) listening. For
the service HTTPS you can also supply a full URL.
A STARTTLS check would be invoked with testssl.sh -t pop3 pop.o2online.de:110. Other examples:
The ports in those examples above are just the standard ports. Also here you're free to check any port.
If you just want to check the mail exchangers of a domain, do it like this:
testssl.sh --mx google.com (make sure port 25 outbound is not blocked
by your firewall) – see left hand side picture.
With the output option --wide you get where possible a wide output
with hexcode of the cipher, OpenSSL cipher suite name, key exchange (with DH size), encryption
algorithm, encryption bits size and maybe the RFC cipher suite name.
If you have the file
mapping-rfc.txt in the same directory as testssl.sh it
displays in the wide outputs also the corresponding RFC style cipher
name. If you don't want this, you need to move mapping-rfc.txt away.
Another thing: If you want to find out what local ciphers you have and print
them pretty, use testssl.sh -V. Ever wondered what hexcode a cipher
is? testssl.sh -V x14 lets you search for the hexcode x14.
For hexcodes: If you just specify 14 instead of x14 you will
get all ciphers returned which have 14 as a low, middle or high byte.
For ciphers: You can also supply a word case pattern,
e.g. testssl.sh -V CBC puts out every locally available cipher having
the Cipher Block Chaining mode in its name.
testssl.sh -x <pattern> <URI> does the same as testssl.sh -V,
it only checks the matched pattern at the server, so e.g. testssl.sh -x ECDH google.com checks google.com
for ECDH ciphers (and lists also not available ones at the target),
testssl.sh -x DHE smtp.posteo.de:465 does
a similar thing for the TLS enabled SMTP service.
testssl.sh --file <myfile> let you do mass testing. The syntax of the file is very easy: one cmdline per line.
Use comment signs # as you like, blank lines will be skipped, EOF signals the end of the file – what else? ;-).
You can also specify a proxy since version 2.6: testssl.sh --proxy=<proxyhost>:<proxyport> <your_other_cmds_here> will sneak the openssl
and bash sockets requests e.g. out of our corporate environment. Proxy authentication is not supported and
the port and protocol has to be allowed in the proxy.
Another neat feature: testssl.sh -H <URI> gives you some information on the HTTP header and marks security features
in green (see upper black picture on the right hand side), not so good headers range from yellow over brown to red. It also allows you to fingerprint proxies, see lower
Which OpenSSL binary?
As mentioned above, a prerequisite for thoroughly checking SSL/TLS enabled servers is that all you want to check for has to be
available on your client. Transport encryption is not only depending on the server but also on your crypto provider on the
client side – especially if you want to use it for testing.
So there are drawbacks for openssl binaries distributed with Linux and BSD:
SSLv2 is most of the time disabled
one cannot check 56 Bit ciphers as they are disabled during compile time.
other ciphers are disabled for security reasons,
zlib support maybe not included (intend was to disable CRIME)
and last but not least: SSLv3 seems to be outphased too
One of the worst test scenarios for testssl.sh is using LibreSSL as it has lots of stuff disabled.
Therefore the signed tarball provides
specially compiled statically linked (except glibc and the loader)
OpenSSL binaries as a courtesy.
It has every dirty feature enabled but also has ChaCha+Poly
ciphers on board. And as an option there are more Linux binaries having
Kerberos ciphers included – the latter ones require a bunch of
libraries (no static binaries). In the end those binaries will give you 191 ciphers + four GOST ciphers as opposed to ~110 from standard Linux
distros! All binaries are compiled from Peter Mosmans OpenSSL fork.
You'll need to unpack the binaries, dump those either in
You can also tell testssl.sh
via environment variable where your openssl binary is:
before you use testssl or using the option --openssl=<path_to_myopenssl>. Last but not least
$PATH is also used to find your OpenSSL binary.
Warning: Don't try outdated OpenSSL versions before 1.0! Those versions are deprecated, you likely will not get very far.
testssl.sh is not locking those versions out yet but things might not work as expected. Support will be retired by Jan 2016.
If you insist on using crippled – in the sense of this tool –
binaries, you'll get a warning in magenta, see e.g. picture on the left hand side (middle of this page).