mirror of
https://github.com/drwetter/testssl.sh.git
synced 2025-10-31 05:45:26 +01:00
da7c713b08
also: * fine tuning protocol section * reference RFC 8470 (well..) and FIPS 203 * add a general linkto TLS related RFCs
1279 lines
74 KiB
HTML
1279 lines
74 KiB
HTML
<!doctype html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<title>testssl.sh</title>
|
||
<style type='text/css' media='all'>
|
||
body {
|
||
margin: 0;
|
||
padding: 0 5ex;
|
||
font-size: 14px;
|
||
font-family: monospace;
|
||
text-align: justify;
|
||
}
|
||
h2, h3, h4, h5, h6 {
|
||
color: #030201;
|
||
}
|
||
h2 {
|
||
font-size: 16px;
|
||
}
|
||
h3 {
|
||
font-size: 15px;
|
||
margin-left: 4ex;
|
||
}
|
||
p, pre, ul, ol, dl {
|
||
margin-left: 8ex;
|
||
}
|
||
code {
|
||
font-weight: bold;
|
||
color:#131211;
|
||
}
|
||
li p {
|
||
margin-left: 0;
|
||
}
|
||
pre > code {
|
||
display: block;
|
||
padding: 0;
|
||
white-space: pre-line;
|
||
}
|
||
ul > li > ul, ul > li > ol {
|
||
margin-left: 0;
|
||
}
|
||
</style>
|
||
</head>
|
||
<body>
|
||
<h2 id="name">NAME</h2>
|
||
<p>testssl.sh – check encryption of SSL/TLS servers</p>
|
||
<h2 id="synopsis">SYNOPSIS</h2>
|
||
<p><code>testssl.sh [OPTIONS] <URI></code>,
|
||
<code>testssl.sh [OPTIONS] --file <FILE></code></p>
|
||
<p>or</p>
|
||
<p><code>testssl.sh [BANNER OPTIONS]</code></p>
|
||
<h2 id="description">DESCRIPTION</h2>
|
||
<p>testssl.sh is a free command line tool which checks a
|
||
server’s service on any port for the support of TLS/SSL ciphers,
|
||
protocols as well as cryptographic flaws and much more.</p>
|
||
<p>The output rates findings by color (screen) or severity (file
|
||
output) so that you are able to tell whether something is good
|
||
or bad. The (screen) output has several sections in which
|
||
classes of checks are being performed. To ease readability on
|
||
the screen it aligns and indents the output properly.</p>
|
||
<p>Only you see the result. You also can use it internally on
|
||
your LAN. Except DNS lookups or unless you instruct testssl.sh
|
||
to check for revocation of certificates it doesn’t use any other
|
||
hosts or even third parties for any test.</p>
|
||
<h2 id="requirements">REQUIREMENTS</h2>
|
||
<p>Testssl.sh is out of the box portable: it runs under any
|
||
Unix-like stack: Linux, *BSD, MacOS X, WSL=Windows Subsystem for
|
||
Linux, Cygwin and MSYS2. <code>bash</code> is a prerequisite,
|
||
also version 3 is still supported. Standard utilities like awk,
|
||
sed, tr and head are also needed. This can be of a BSD, System 5
|
||
or GNU flavor whereas grep from System V is not yet
|
||
supported.</p>
|
||
<p>Any OpenSSL or LibreSSL version is needed as a helper. Unlike
|
||
previous versions of testssl.sh almost every check is done via
|
||
(TCP) sockets. In addition statically linked OpenSSL binaries
|
||
for major operating systems are supplied in
|
||
<code>./bin/</code>.</p>
|
||
<h2 id="general">GENERAL</h2>
|
||
<p><code>testssl.sh URI</code> as the default invocation does
|
||
the so-called default run which does a number of checks and puts
|
||
out the results colorized (ANSI and termcap) on the screen. It
|
||
does every check listed below except <code>-E</code> which are
|
||
(order of appearance):</p>
|
||
<ol start="0" type="1">
|
||
<li><p>displays a banner (see below), does a DNS lookup also for
|
||
further IP addresses and does for the returned IP address a
|
||
reverse lookup. Last but not least a service check is being
|
||
done.</p></li>
|
||
<li><p>SSL/TLS protocol check</p></li>
|
||
<li><p>standard cipher categories</p></li>
|
||
<li><p>server’s cipher preferences (server order?)</p></li>
|
||
<li><p>forward secrecy: ciphers and elliptical curves</p></li>
|
||
<li><p>server defaults (certificate info, TLS extensions,
|
||
session information)</p></li>
|
||
<li><p>HTTP header (if HTTP detected or being forced via
|
||
<code>--assume-http</code>)</p></li>
|
||
<li><p>vulnerabilities</p></li>
|
||
<li><p>testing each of 370 preconfigured ciphers</p></li>
|
||
<li><p>client simulation</p></li>
|
||
<li><p>rating</p></li>
|
||
</ol>
|
||
<p>If a target FQDN has multiple IPv4 and/or multiple IPv6
|
||
addresses, it scans all IPs with the specified options or using
|
||
the default run - unless specified otherwise, see
|
||
<code>--ip</code>, <code>-4</code> and <code>-6</code>. IPv6
|
||
connectivity is automagically checked. If there’s noch such
|
||
thing you will see a banner <em>Testing all
|
||
<strong>IPv4</strong> addresses</em> and all IPv6 addresses will
|
||
appear in round brackets.</p>
|
||
<h2 id="options-and-parameters">OPTIONS AND PARAMETERS</h2>
|
||
<p>Options are either short or long options. Any long or short
|
||
option requiring a value can be called with or without an equal
|
||
sign. E.g.
|
||
<code>testssl.sh -t=smtp --wide --openssl=/usr/bin/openssl <URI></code>
|
||
(short options with equal sign) is equivalent to
|
||
<code>testssl.sh --starttls smtp --wide --openssl /usr/bin/openssl <URI></code>
|
||
(long option without equal sign). Some command line options can
|
||
also be preset via ENV variables.
|
||
<code>WIDE=true OPENSSL=/usr/bin/openssl testssl.sh --starttls=smtp <URI></code>
|
||
would be the equivalent to the aforementioned examples.
|
||
Preference has the command line over any environment
|
||
variables.</p>
|
||
<p><code><URI></code> or <code>--file <FILE></code>
|
||
always needs to be the last parameter.</p>
|
||
<h3 id="banner-options-standalone">BANNER OPTIONS
|
||
(standalone)</h3>
|
||
<p><code>--help</code> (or no arg) displays command line
|
||
help</p>
|
||
<p><code>-b, --banner</code> displays testssl.sh banner,
|
||
including license, usage conditions, version of testssl.sh,
|
||
detected openssl version, its path to it, # of ciphers of
|
||
openssl, its build date and the architecture.</p>
|
||
<p><code>-v, --version</code> same as before</p>
|
||
<p><code>-V [pattern], --local [pattern]</code> pretty print all
|
||
local ciphers supported by openssl version. If a pattern is
|
||
supplied it performs a match (ignore case) on any of the strings
|
||
supplied in the wide output, see below. The pattern will be
|
||
searched in the any of the columns: hexcode, cipher suite name
|
||
(OpenSSL or IANA), key exchange, encryption, bits. It does a
|
||
word pattern match for non-numbers, for number just a normal
|
||
match applies. Numbers here are defined as [0-9,A-F]. This means
|
||
(attention: catch) that the pattern CBC is matched as non-word,
|
||
but AES as word. This option also accepts
|
||
<code>--openssl=<path_to_openssl></code>.</p>
|
||
<h3 id="input-parameters">INPUT PARAMETERS</h3>
|
||
<p><code>URI</code> can be a hostname, an IPv4 or IPv6 address
|
||
(restriction see below) or an URL. IPv6 addresses need to be in
|
||
square brackets. For any given parameter port 443 is assumed
|
||
unless specified by appending a colon and a port number. The
|
||
only preceding protocol specifier allowed is <code>https</code>.
|
||
You need to be aware that checks for an IP address might not hit
|
||
the vhost you want. DNS resolution (A/AAAA record) is being
|
||
performed unless you have an <code>/etc/hosts</code> entry for
|
||
the hostname.</p>
|
||
<p><code>--file <fname></code> or the equivalent
|
||
<code>-iL <fname></code> are mass testing options. Per
|
||
default it implicitly turns on <code>--warnings batch</code>,
|
||
unless warnings has been set to off before. In its first
|
||
incarnation the mass testing option reads command lines from
|
||
<code>fname</code>. <code>fname</code> consists of command lines
|
||
of testssl, one line per instance. Comments after <code>#</code>
|
||
are ignored, <code>EOF</code> signals the end of fname any
|
||
subsequent lines will be ignored too. You can also supply
|
||
additional options which will be inherited to each child,
|
||
e.g. When invoking
|
||
<code>testssl.sh --wide --log --file <fname></code> . Each
|
||
single line in <code>fname</code> is parsed upon execution. If
|
||
there’s a conflicting option and serial mass testing option is
|
||
being performed the check will be aborted at the time it occurs
|
||
and depending on the output option potentially leaving you with
|
||
an output file without footer. In parallel mode the mileage
|
||
varies, likely a line won’t be scanned.</p>
|
||
<p>Alternatively <code>fname</code> can be in
|
||
<code>nmap</code>’s grep(p)able output format
|
||
(<code>-oG</code>). Only open ports will be considered. Multiple
|
||
ports per line are allowed. The ports can be different and will
|
||
be tested by testssl.sh according to common practice in the
|
||
internet, i.e. if nmap shows in its output an open port 25,
|
||
automatically <code>-t smtp</code> will be added before the URI
|
||
whereas port 465 will be treated as a plain TLS/SSL port, not
|
||
requiring an STARTTLS SMTP handshake upfront. This is done by an
|
||
internal table which correlates nmap’s open port detected to the
|
||
STARTTLS/plain text decision from testssl.sh.</p>
|
||
<p>Nmap’s output always returns IP addresses and only if there’s
|
||
a PTR DNS record available a hostname. As it is not checked by
|
||
nmap whether the hostname matches the IP (A or AAAA record),
|
||
testssl.sh does this automatically for you. If the A record of
|
||
the hostname matches the IP address, the hostname is used and
|
||
not the IP address. Please keep in mind that checks against an
|
||
IP address might not hit the vhost you maybe were aiming at and
|
||
thus it may lead to different results.</p>
|
||
<p>A typical internal conversion to testssl.sh file format from
|
||
nmap’s grep(p)able format could look like:</p>
|
||
<pre><code> 10.10.12.16:443
|
||
10.10.12.16:1443
|
||
-t smtp host.example.com:25
|
||
host.example.com:443
|
||
host.example.com:631
|
||
-t ftp 10.10.12.11:21
|
||
10.10.12.11:8443</code></pre>
|
||
<p>Please note that <code>fname</code> has to be in Unix format.
|
||
DOS carriage returns won’t be accepted. Instead of the command
|
||
line switch the environment variable FNAME will be honored
|
||
too.</p>
|
||
<p><code>--mode <serial|parallel></code>. Mass testing to
|
||
be done serial (default) or parallel (<code>--parallel</code> is
|
||
shortcut for the latter, <code>--serial</code> is the opposite
|
||
option). Per default mass testing is being run in serial mode,
|
||
i.e. one line after the other is processed and invoked. The
|
||
variable <code>MASS_TESTING_MODE</code> can be defined to be
|
||
either equal <code>serial</code> or <code>parallel</code>.</p>
|
||
<p><code>--warnings <batch|off></code>. The warnings
|
||
parameter determines how testssl.sh will deal with situations
|
||
where user input normally will be necessary. There are two
|
||
options. <code>batch</code> doesn’t wait for a confirming
|
||
keypress when a client- or server-side problem is encountered.
|
||
As of 3.0 it just then terminates the particular scan. This is
|
||
automatically chosen for mass testing (<code>--file</code>).
|
||
<code>off</code> just skips the warning, the confirmation but
|
||
continues the scan, independent whether it makes sense or not.
|
||
Please note that there are conflicts where testssl.sh will still
|
||
ask for confirmation which are the ones which otherwise would
|
||
have a drastic impact on the results. Almost any other decision
|
||
will be made in the future as a best guess by testssl.sh. The
|
||
same can be achieved by setting the environment variable
|
||
<code>WARNINGS</code>.</p>
|
||
<p><code>--socket-timeout <seconds></code> This is useful
|
||
for socket TCP connections to a node. If the node does not
|
||
complete a TCP handshake (e.g. because it is down or behind a
|
||
firewall or there’s an IDS or a tarpit) testssl.sh may usually
|
||
hang for around 2 minutes or even much more. This parameter
|
||
instructs testssl.sh to wait at most <code>seconds</code> for
|
||
the handshake to complete before giving up. This option only
|
||
works if your OS has a timeout binary installed. SOCKET_TIMEOUT
|
||
is the corresponding environment variable. This doesn’t work on
|
||
Macs out of the box.</p>
|
||
<p><code>--openssl-timeout <seconds></code> This is
|
||
especially useful for all connects using openssl and practically
|
||
useful for mass testing. It avoids the openssl connect to hang
|
||
for ~2 minutes. The expected parameter <code>seconds</code>
|
||
instructs testssl.sh to wait before the openssl connect will be
|
||
terminated. The option is only available if your OS has a
|
||
timeout binary installed. As there are different implementations
|
||
of <code>timeout</code>: It automatically calls the binary with
|
||
the right parameters. OPENSSL_TIMEOUT is the equivalent
|
||
environment variable. This doesn’t work on Macs out of the
|
||
box.</p>
|
||
<p><code>--basicauth <user:pass></code> This can be set to
|
||
provide HTTP basic auth credentials which are used during checks
|
||
for security headers. BASICAUTH is the ENV variable you can use
|
||
instead.</p>
|
||
<p><code>--reqheader <header></code> This can be used to
|
||
add additional HTTP request headers in the correct format
|
||
<code>Headername: headercontent</code>. This parameter can be
|
||
called multiple times if required. For example:
|
||
<code>--reqheader 'Proxy-Authorization: Basic dGVzdHNzbDpydWxlcw==' --reqheader 'ClientID: 0xDEADBEAF'</code>.
|
||
REQHEADER is the corresponding environment variable.</p>
|
||
<p><code>--mtls <path_to_client_cert></code> This can be
|
||
set to provide a file containing a client certificatete and a
|
||
private key (not encrypted) in PEM format, which is used when a
|
||
mutual TLS authentication is required by the remote server. MTLS
|
||
is the equivalent environment variable.</p>
|
||
<h3 id="special-invocations">SPECIAL INVOCATIONS</h3>
|
||
<p><code>-t <protocol>, --starttls <protocol></code>
|
||
does a default run against a STARTTLS enabled
|
||
<code>protocol</code>. <code>protocol</code> must be one of
|
||
<code>ftp</code>, <code>smtp</code>, <code>pop3</code>,
|
||
<code>imap</code>, <code>xmpp</code>, <code>sieve</code>,
|
||
<code>xmpp-server</code>, <code>telnet</code>,
|
||
<code>ldap</code>, <code>irc</code>, <code>lmtp</code>,
|
||
<code>nntp</code>, <code>postgres</code>, <code>mysql</code>.
|
||
For the latter four you need e.g. the supplied OpenSSL or
|
||
OpenSSL version 1.1.1. Please note: MongoDB doesn’t offer a
|
||
STARTTLS connection, IRC currently only works with
|
||
<code>--ssl-native</code>. <code>irc</code> is WIP.</p>
|
||
<p><code>--xmpphost <jabber_domain></code> is an
|
||
additional option for STARTTLS enabled XMPP: It expects the
|
||
jabber domain as a parameter. This is only needed if the domain
|
||
is different from the URI supplied.</p>
|
||
<p><code>--mx <domain|host></code> tests all MX records
|
||
(STARTTLS on port 25) from high to low priority, one after the
|
||
other.</p>
|
||
<p><code>--ip <ip></code> tests either the supplied IPv4
|
||
or IPv6 address instead of resolving host(s) in
|
||
<code><URI></code>. IPv6 addresses need to be supplied in
|
||
square brackets. <code>--ip=one</code> means: just test the
|
||
first A record DNS returns (useful for multiple IPs). If
|
||
<code>-6</code> and <code>--ip=one</code> was supplied an AAAA
|
||
record will be picked if available. The <code>--ip</code> option
|
||
might be also useful if you want to resolve the supplied
|
||
hostname to a different IP, similar as if you would edit
|
||
<code>/etc/hosts</code> or
|
||
<code>/c/Windows/System32/drivers/etc/hosts</code>.
|
||
<code>--ip=proxy</code> tries a DNS resolution via proxy.
|
||
<code>--ip=proxy</code> plus <code>--nodns=min</code> is useful
|
||
for situations with no local DNS as there’ll be no DNS timeouts
|
||
when trying to resolve CAA, TXT and MX records.</p>
|
||
<p><code>--proxy <host>:<port></code> does ANY check
|
||
via the specified proxy. <code>--proxy=auto</code> inherits the
|
||
proxy setting from the environment. Any hostname supplied will
|
||
be resolved to the first A record, if it does not exist the AAAA
|
||
record is used. IPv4 and IPv6 addresses can be passed too, the
|
||
latter <em>also</em> with square bracket notation. Please note
|
||
that you need a newer OpenSSL or LibreSSL version for IPv6 proxy
|
||
functionality. In addition if you want lookups via proxy you can
|
||
specify <code>DNS_VIA_PROXY=true</code>. OCSP revocation
|
||
checking (<code>-S --phone-out</code>) is not supported by
|
||
OpenSSL via proxy. As supplying a proxy is an indicator for port
|
||
80 and 443 outgoing being blocked in your network an OCSP
|
||
revocation check won’t be performed. However if
|
||
<code>IGN_OCSP_PROXY=true</code> has been supplied it will be
|
||
tried directly. Authentication to the proxy is not supported,
|
||
also no HTTPS or SOCKS proxy.</p>
|
||
<p><code>-6</code> scans only IPv6 addresses of the target.
|
||
Besides the OpenSSL binary supplied IPv6 is known to work with
|
||
vanilla OpenSSL >= 1.1.0 and older versions >=1.0.2 in
|
||
RHEL/CentOS/FC and Gentoo. Scans are somewhat in line with tools
|
||
like curl or wget, i.e. if there’s an IPv6 address of the target
|
||
which can be reached, it just uses them. If you don’t want this
|
||
behavior, you need to supply <code>-4.</code></p>
|
||
<p><code>-4</code> scans only IPv4 addresses of the target, IPv6
|
||
addresses of the target won’t be scanned.</p>
|
||
<p><code>--ssl-native</code> Instead of using a mixture of bash
|
||
sockets and a few openssl s_client connects, testssl.sh uses the
|
||
latter (almost) only. This is faster but provides less accurate
|
||
results, especially for the client simulation and for cipher
|
||
support. For all checks you will see a warning if testssl.sh
|
||
cannot tell if a particular check cannot be performed. For some
|
||
checks however you might end up getting false negatives without
|
||
a warning. Thus it is not recommended to use. It should only be
|
||
used if you prefer speed over accuracy or you know that your
|
||
target has sufficient overlap with the protocols and cipher
|
||
provided by your openssl binary.</p>
|
||
<p><code>--openssl <path_to_openssl></code> testssl.sh
|
||
tries first very hard to find the binary supplied (where the
|
||
tree of testssl.sh resides, from the directory where testssl.sh
|
||
has been started from, etc.). If all that doesn’t work it falls
|
||
back to openssl supplied from the OS (<code>$PATH</code>). With
|
||
this option you can point testssl.sh to your binary of choice
|
||
and override any internal magic to find the openssl binary.
|
||
(Environment preset via
|
||
<code>OPENSSL=<path_to_openssl></code>). Depending on your
|
||
test parameters it could be faster to pick the OpenSSL version
|
||
which has a bigger overlap in terms of ciphers protocols with
|
||
the target. Also, when testing a modern server, OpenSSL 3.X is
|
||
faster than older OpenSSL versions, or on MacOS 18, as opposed
|
||
to the provided LibreSSL version.</p>
|
||
<h3 id="tuning-options">TUNING OPTIONS</h3>
|
||
<p><code>--bugs</code> does some workarounds for buggy servers
|
||
like padding for old F5 devices. The option is passed as
|
||
<code>-bug</code> to openssl when needed, see
|
||
<code>s_client(1)</code>, environment preset via
|
||
<code>BUGS="-bugs"</code> (1x dash). For the socket part
|
||
testssl.sh has always workarounds in place to cope with broken
|
||
server implementations.</p>
|
||
<p><code>--assuming-http</code> testssl.sh normally does upfront
|
||
an application protocol detection. In cases where HTTP cannot be
|
||
automatically detected you may want to use this option. It
|
||
enforces testssl.sh not to skip HTTP specific tests (HTTP
|
||
header) and to run a browser based client simulation. Please
|
||
note that sometimes also the severity depends on the application
|
||
protocol, e.g. SHA1 signed certificates, the lack of any SAN
|
||
matches and some vulnerabilities will be punished harder when
|
||
checking a web server as opposed to a mail server.</p>
|
||
<p><code>-n, --nodns <min|none></code> tells testssl.sh
|
||
which DNS lookups should be performed. <code>min</code> uses
|
||
only forward DNS resolution (A and AAAA record or MX record) and
|
||
skips CAA lookups and PTR records from the IP address back to a
|
||
DNS name. <code>none</code> performs no DNS lookups at all. For
|
||
the latter you either have to supply the IP address as a target,
|
||
to use <code>--ip</code> or have the IP address in
|
||
<code>/etc/hosts</code>. The use of the switch is only useful if
|
||
you either can’t or are not willing to perform DNS lookups. The
|
||
latter can apply e.g. to some pentests. In general this option
|
||
could e.g. help you to avoid timeouts by DNS lookups.
|
||
<code>NODNS</code> is the environment variable for this.
|
||
<code>--nodns=min</code> plus <code>--ip=proxy</code> is useful
|
||
for situations with no local DNS as there’ll be no DNS timeouts
|
||
when trying to resolve CAA, TXT and MX records.</p>
|
||
<p><code>--sneaky</code> For HTTP header checks testssl.sh uses
|
||
normally the server friendly HTTP user agent
|
||
<code>TLS tester from ${URL}</code>. With this option your
|
||
traces are less verbose and a Firefox user agent is being used.
|
||
Be aware that it doesn’t hide your activities. That is just not
|
||
possible (environment preset via <code>SNEAKY=true</code>).</p>
|
||
<p><code>--user-agent <user agent></code> tells testssl.sh
|
||
to use the supplied HTTP user agent instead of the standard user
|
||
agent <code>TLS tester from ${URL}</code>.</p>
|
||
<p><code>--ids-friendly</code> is a switch which may help to get
|
||
a scan finished which otherwise would be blocked by a server
|
||
side IDS. This switch skips tests for the following
|
||
vulnerabilities: Heartbleed, CCS Injection, Ticketbleed and
|
||
ROBOT. The environment variable OFFENSIVE set to false will
|
||
achieve the same result. Please be advised that as an
|
||
alternative or as a general approach you can try to apply
|
||
evasion techniques by changing the variables USLEEP_SND and / or
|
||
USLEEP_REC and maybe MAX_WAITSOCK.</p>
|
||
<p><code>--phone-out</code> Checking for revoked certificates
|
||
via CRL and OCSP is not done per default. This switch instructs
|
||
testssl.sh to query external – in a sense of the current run –
|
||
URIs. By using this switch you acknowledge that the check might
|
||
have privacy issues, a download of several megabytes (CRL file)
|
||
may happen and there may be network connectivity problems while
|
||
contacting the endpoint which testssl.sh doesn’t handle.
|
||
PHONE_OUT is the environment variable for this which needs to be
|
||
set to true if you want this.</p>
|
||
<p><code>--add-ca <CAfile></code> enables you to add your
|
||
own CA(s) in PEM format for trust chain checks.
|
||
<code>CAfile</code> can be a directory containing files with a
|
||
.pem extension, a single file or multiple files as a comma
|
||
separated list of root CAs. Internally they will be added during
|
||
runtime to all CA stores. This is (only) useful for internal
|
||
hosts whose certificates are issued by internal CAs.
|
||
Alternatively ADDTL_CA_FILES is the environment variable for
|
||
this.</p>
|
||
<h3 id="single-check-options">SINGLE CHECK OPTIONS</h3>
|
||
<p>Any single check switch supplied as an argument prevents
|
||
testssl.sh from doing a default run. It just takes this and if
|
||
supplied other options and runs them - in the order they would
|
||
also appear in the default run.</p>
|
||
<p><code>-e, --each-cipher</code> checks each of the (currently
|
||
configured) 370 ciphers via openssl + sockets remotely on the
|
||
server and reports back the result in wide mode. If you want to
|
||
display each cipher tested you need to add
|
||
<code>--show-each</code>. Per default it lists the following
|
||
parameters: <code>hexcode</code>,
|
||
<code>OpenSSL cipher suite name</code>,
|
||
<code>key exchange</code>, <code>encryption bits</code>,
|
||
<code>IANA/RFC cipher suite name</code>. Please note the
|
||
<code>--mapping</code> parameter changes what cipher suite names
|
||
you will see here and at which position. Also please note that
|
||
the <strong>bit</strong> length for the encryption is shown and
|
||
not the <strong>security</strong> length, albeit it’ll be sorted
|
||
by the latter. For 3DES due to the Meet-in-the-Middle problem
|
||
the bit size of 168 bits is equivalent to the security size of
|
||
112 bits.</p>
|
||
<p><code>-E, --cipher-per-proto</code> is similar to
|
||
<code>-e, --each-cipher</code>. It checks each of the possible
|
||
ciphers, here: per protocol. If you want to display each cipher
|
||
tested you need to add <code>--show-each</code>. The output is
|
||
sorted by security strength, it lists the encryption bits
|
||
though.</p>
|
||
<p><code>-s, --std, --categories</code> tests certain lists of
|
||
cipher suites / cipher categories by strength.
|
||
(<code>--standard</code> is deprecated.) Those lists are
|
||
(<code>openssl ciphers $LIST</code>, $LIST from below:)</p>
|
||
<ul>
|
||
<li><code>NULL encryption ciphers</code>: ‘NULL:eNULL’</li>
|
||
<li><code>Anonymous NULL ciphers</code>: ‘aNULL:ADH’</li>
|
||
<li><code>Export ciphers</code> (w/o the preceding ones):
|
||
‘EXPORT:!ADH:!NULL’</li>
|
||
<li><code>LOW</code> (64 Bit + DES ciphers, without EXPORT
|
||
ciphers):
|
||
‘LOW:DES:RC2:RC4:MD5:!ADH:!EXP:!NULL:!eNULL:!AECDH’</li>
|
||
<li><code>3DES + IDEA ciphers</code>:
|
||
‘3DES:IDEA:!aNULL:!ADH:!MD5’</li>
|
||
<li><code>Obsoleted CBC ciphers</code>:
|
||
‘HIGH:MEDIUM:AES:CAMELLIA:ARIA:!IDEA:!CHACHA20:!3DES:!RC2:!RC4:!AESCCM8:!AESCCM:!AESGCM:!ARIAGCM:!aNULL:!MD5’</li>
|
||
<li><code>Strong ciphers with no FS</code> (AEAD):
|
||
‘AESGCM:CHACHA20:CamelliaGCM:AESCCM:ARIAGCM:!kEECDH:!kEDH:!kDHE:!kDHEPSK:!kECDHEPSK:!aNULL’</li>
|
||
<li><code>Forward Secrecy strong ciphers</code> (AEAD):
|
||
‘AESGCM:CHACHA20:CamelliaGCM:AESCCM:ARIAGCM:!kPSK:!kRSAPSK:!kRSA:!kDH:!kECDH:!aNULL’</li>
|
||
</ul>
|
||
<p><code>-f, --fs, --nsa, --forward-secrecy</code> Checks robust
|
||
forward secrecy key exchange. “Robust” means that ciphers having
|
||
intrinsic severe weaknesses like Null Authentication or
|
||
Encryption, 3DES and RC4 won’t be considered here. There
|
||
shouldn’t be the wrong impression that a secure key exchange has
|
||
been taking place and everything is fine when in reality the
|
||
encryption sucks. Also this section lists the available
|
||
elliptical curves and Diffie Hellman groups, as well as FFDHE
|
||
groups (TLS 1.2 and TLS 1.3).</p>
|
||
<p><code>-p, --protocols</code> checks every SSL/TLS protocols:
|
||
SSLv2, SSLv3, TLS 1.0 through TLS 1.3. And for HTTP also QUIC
|
||
(HTTP/3), SPDY (NPN) and ALPN (HTTP/2). For TLS 1.3 the final
|
||
version and several drafts (from 18 on) are tested. QUIC needs
|
||
OpenSSL >= 3.2 which can be automatically picked up when in
|
||
<code>/usr/bin/openssl</code> (or when defined environment
|
||
variable OPENSSL2). If a TLS-1.3-only host is encountered and
|
||
the openssl-bad version is used testssl.sh will e.g. for HTTP
|
||
header checks switch to <code>/usr/bin/openssl</code> (or when
|
||
defined via ENV to OPENSSL2). Also this will be tried for the
|
||
QUIC check.</p>
|
||
<p><code>-P, --server-preference, --preference</code> displays
|
||
the servers preferences: cipher order, with used openssl client:
|
||
negotiated protocol and cipher. If there’s a cipher order
|
||
enforced by the server it displays it for each protocol
|
||
(openssl+sockets). If there’s not, it displays instead which
|
||
ciphers from the server were picked with each protocol.</p>
|
||
<p><code>-S, --server_defaults</code> displays information from
|
||
the server hello(s):</p>
|
||
<ul>
|
||
<li>Available TLS extensions,</li>
|
||
<li>TLS ticket + session ID information/capabilities,</li>
|
||
<li>session resumption capabilities,</li>
|
||
<li>TLS 1.3 early data, a.k.a 0-RTT</li>
|
||
<li>Time skew relative to localhost (most server implementations
|
||
return random values).</li>
|
||
<li>Several certificate information
|
||
<ul>
|
||
<li>signature algorithm,</li>
|
||
<li>key size,</li>
|
||
<li>key usage and extended key usage,</li>
|
||
<li>fingerprints and serial</li>
|
||
<li>Common Name (CN), Subject Alternative Name (SAN),
|
||
Issuer,</li>
|
||
<li>Trust via hostname + chain of trust against supplied
|
||
certificates</li>
|
||
<li>EV certificate detection</li>
|
||
<li>experimental “eTLS” detection</li>
|
||
<li>validity: start + end time, how many days to go (warning for
|
||
certificate lifetime >=5 years)</li>
|
||
<li>revocation info (CRL, OCSP, OCSP stapling + must staple).
|
||
When <code>--phone-out</code> supplied it checks against the
|
||
certificate issuer whether the host certificate has been revoked
|
||
(plain OCSP, CRL).</li>
|
||
<li>displaying DNS Certification Authority Authorization
|
||
resource record</li>
|
||
<li>Certificate Transparency info (if provided by server).</li>
|
||
</ul></li>
|
||
</ul>
|
||
<p>For the trust chain check 5 certificate stores are provided.
|
||
If the test against one of the trust stores failed, the one is
|
||
being identified and the reason for the failure is displayed -
|
||
in addition the ones which succeeded are displayed too. You can
|
||
configure your own CA via ADDTL_CA_FILES, see section
|
||
<code>FILES</code> below. If the server provides no matching
|
||
record in Subject Alternative Name (SAN) but in Common Name
|
||
(CN), it will be indicated as this is deprecated. Also for
|
||
multiple server certificates are being checked for as well as
|
||
for the certificate reply to a non-SNI (Server Name Indication)
|
||
client hello to the IP address. Regarding the TLS clock skew: it
|
||
displays the time difference to the client. Only a few TLS
|
||
stacks nowadays still support this and return the local clock
|
||
<code>gmt_unix_time</code>, e.g. IIS, openssl < 1.0.1f. In
|
||
addition to the HTTP date you could e.g. derive that there are
|
||
different hosts where your TLS and your HTTP request ended – if
|
||
the time deltas differ significantly.</p>
|
||
<p><code>-x <pattern>, --single-cipher <pattern></code>
|
||
tests matched <code>pattern</code> of ciphers against a server.
|
||
Patterns are similar to
|
||
<code>-V pattern , --local pattern</code>, see above about
|
||
matching.</p>
|
||
<p><code>-h, --header, --headers</code> if the service is HTTP
|
||
(either by detection or by enforcing via
|
||
<code>--assume-http</code>. It tests several HTTP headers
|
||
like</p>
|
||
<ul>
|
||
<li>HTTP Strict Transport Security (HSTS)</li>
|
||
<li>HTTP Public Key Pinning (HPKP)</li>
|
||
<li>Server banner</li>
|
||
<li>HTTP date+time</li>
|
||
<li>Server banner like Linux or other Unix vendor headers</li>
|
||
<li>Application banner (PHP, RoR, OWA, SharePoint, Wordpress,
|
||
etc)</li>
|
||
<li>Reverse proxy headers</li>
|
||
<li>Web server modules</li>
|
||
<li>IPv4 address in header</li>
|
||
<li>Cookie (including Secure/HTTPOnly flags)</li>
|
||
<li>Decodes BIG IP F5 non-encrypted cookies</li>
|
||
<li>Security headers (X-Frame-Options, X-XSS-Protection,
|
||
Expect-CT,… , CSP headers). Nonsense is not yet detected
|
||
here.</li>
|
||
</ul>
|
||
<p><code>-c, --client-simulation</code> This simulates a
|
||
handshake with a number of standard clients so that you can
|
||
figure out which client cannot or can connect to your site. For
|
||
the latter case the protocol, cipher and curve is displayed,
|
||
also if there’s Forward Secrecy. testssl.sh uses a handselected
|
||
set of clients which are retrieved by the SSLlabs API. The
|
||
output is aligned in columns when combined with the
|
||
<code>--wide</code> option. If you want the full nine yards of
|
||
clients displayed use the environment variable ALL_CLIENTS.</p>
|
||
<p><code>-g, --grease</code> checks several server
|
||
implementation bugs like tolerance to size limitations and
|
||
GREASE, see RFC 8701. This check doesn’t run per default.</p>
|
||
<h3 id="vulnerabilities">VULNERABILITIES</h3>
|
||
<p><code>-U, --vulnerable, --vulnerabilities</code> Just tests
|
||
all (of the following) vulnerabilities. The environment variable
|
||
<code>VULN_THRESHLD</code> determines after which value a
|
||
separate headline for each vulnerability is being displayed.
|
||
Default is <code>1</code> which means if you check for two
|
||
vulnerabilities, only the general headline for vulnerabilities
|
||
section is displayed – in addition to the vulnerability and the
|
||
result. Otherwise each vulnerability or vulnerability section
|
||
gets its own headline in addition to the output of the name of
|
||
the vulnerability and test result. A vulnerability section is
|
||
comprised of more than one check, e.g. the renegotiation
|
||
vulnerability check has two checks, so has Logjam.</p>
|
||
<p><code>-H, --heartbleed</code> Checks for Heartbleed, a memory
|
||
leakage in openssl. Unless the server side doesn’t support the
|
||
heartbeat extension it is likely that this check runs into a
|
||
timeout. The seconds to wait for a reply can be adjusted with
|
||
<code>HEARTBLEED_MAX_WAITSOCK</code>. 8 is the default.</p>
|
||
<p><code>-I, --ccs, --ccs-injection</code> Checks for CCS
|
||
Injection which is an openssl vulnerability. Sometimes also here
|
||
the check needs to wait for a reply. The predefined timeout of 5
|
||
seconds can be changed with the environment variable
|
||
<code>CCS_MAX_WAITSOCK</code>.</p>
|
||
<p><code>-T, --ticketbleed</code> Checks for Ticketbleed memory
|
||
leakage in BigIP loadbalancers.</p>
|
||
<p><code>--OP, --opossum</code> Checks for HTTP to HTTPS upgrade
|
||
vulnerability named Opossum.</p>
|
||
<p><code>--BB, --robot</code> Checks for vulnerability to ROBOT
|
||
/ (<em>Return Of Bleichenbacher’s Oracle Threat</em>)
|
||
attack.</p>
|
||
<p><code>--SI, --starttls-injection</code> Checks for STARTTLS
|
||
injection vulnerabilities (SMTP, IMAP, POP3 only).
|
||
<code>socat</code> and OpenSSL >=1.1.0 is needed.</p>
|
||
<p><code>-R, --renegotiation</code> Tests renegotiation
|
||
vulnerabilities. Currently there’s a check for <em>Secure
|
||
Renegotiation</em> and for <em>Secure Client-Initiated
|
||
Renegotiation</em>. Please be aware that vulnerable servers to
|
||
the latter can likely be DoSed very easily (HTTP). A check for
|
||
<em>Insecure Client-Initiated Renegotiation</em> is not yet
|
||
implemented.</p>
|
||
<p><code>-C, --compression, --crime</code> Checks for CRIME
|
||
(<em>Compression Ratio Info-leak Made Easy</em>) vulnerability
|
||
in TLS. CRIME in SPDY is not yet being checked for.</p>
|
||
<p><code>-B, --breach</code> Checks for BREACH (<em>Browser
|
||
Reconnaissance and Exfiltration via Adaptive Compression of
|
||
Hypertext</em>) vulnerability. As for this vulnerability HTTP
|
||
level compression is a prerequisite it’ll be not tested if HTTP
|
||
cannot be detected or the detection is not enforced via
|
||
<code>--assume-http</code>. Please note that only the URL
|
||
supplied (normally “/” ) is being tested.</p>
|
||
<p><code>-O, --poodle</code> Tests for SSL POODLE (<em>Padding
|
||
Oracle On Downgraded Legacy Encryption</em>) vulnerability. It
|
||
basically checks for the existence of CBC ciphers in SSLv3.</p>
|
||
<p><code>-Z, --tls-fallback</code> Checks TLS_FALLBACK_SCSV
|
||
mitigation. TLS_FALLBACK_SCSV is basically a ciphersuite
|
||
appended to the Client Hello trying to prevent protocol
|
||
downgrade attacks by a Man in the Middle.</p>
|
||
<p><code>-W, --sweet32</code> Checks for vulnerability to
|
||
SWEET32 by testing 64 bit block ciphers (3DES, RC2 and
|
||
IDEA).</p>
|
||
<p><code>-F, --freak</code> Checks for FREAK vulnerability
|
||
(<em>Factoring RSA Export Keys</em>) by testing for EXPORT RSA
|
||
ciphers</p>
|
||
<p><code>-D, --drown</code> Checks for DROWN vulnerability
|
||
(<em>Decrypting RSA with Obsolete and Weakened eNcryption</em>)
|
||
by checking whether the SSL 2 protocol is available at the
|
||
target. Please note that if you use the same RSA certificate
|
||
elsewhere you might be vulnerable too. testssl.sh doesn’t check
|
||
for this but provides a helpful link @ censys.io which provides
|
||
this service.</p>
|
||
<p><code>-J, --logjam</code> Checks for LOGJAM vulnerability by
|
||
checking for DH EXPORT ciphers. It also checks for “common
|
||
primes” which are preconfigured DH keys. DH keys =< 1024 Bit
|
||
will be penalized. Also FFDHE groups (TLS 1.2) will be displayed
|
||
here.</p>
|
||
<p><code>-A, --beast</code> Checks BEAST vulnerabilities in SSL
|
||
3 and TLS 1.0 by testing the usage of CBC ciphers.</p>
|
||
<p><code>-L, --lucky13</code> Checks for LUCKY13 vulnerability.
|
||
It checks for the presence of CBC ciphers in TLS versions 1.0 -
|
||
1.2.</p>
|
||
<p><code>-WS, --winshock</code> Checks for Winshock
|
||
vulnerability. It tests for the absence of a lot of ciphers,
|
||
some TLS extensions and ec curves which were introduced later in
|
||
Windows. In the end the server banner is being looked at.</p>
|
||
<p><code>--rc4, --appelbaum</code> Checks which RC4 stream
|
||
ciphers are being offered.</p>
|
||
<h3 id="output-options">OUTPUT OPTIONS</h3>
|
||
<p><code>-q, --quiet</code> Normally testssl.sh displays a
|
||
banner on stdout with several version information, usage rights
|
||
and a warning. This option suppresses it. Please note that by
|
||
choosing this option you acknowledge usage terms and the warning
|
||
normally appearing in the banner.</p>
|
||
<p><code>--wide</code> Except the “each cipher output” all tests
|
||
displays the single cipher name (scheme see below). This option
|
||
enables testssl.sh to display also for the following sections
|
||
the same output as for testing each ciphers: BEAST, FS, RC4. The
|
||
client simulation has also a wide mode. The difference here is
|
||
restricted to a column aligned output and a proper headline. The
|
||
environment variable <code>WIDE</code> can be used instead.</p>
|
||
<p><code>--mapping <openssl|iana|no-openssl|no-iana></code></p>
|
||
<ul>
|
||
<li><code>openssl</code>: use the OpenSSL cipher suite name as
|
||
the primary name cipher suite name form (default),</li>
|
||
<li><code>iana</code>: use the IANA cipher suite name as the
|
||
primary name cipher suite name form.</li>
|
||
<li><code>no-openssl</code>: don’t display the OpenSSL cipher
|
||
suite name, display IANA names only.</li>
|
||
<li><code>no-iana</code>: don’t display the IANA cipher suite
|
||
name, display OpenSSL names only.</li>
|
||
</ul>
|
||
<p>Please note that in testssl.sh 3.0 you can still use
|
||
<code>rfc</code> instead of <code>iana</code> and
|
||
<code>no-rfc</code> instead of <code>no-iana</code> but it’ll
|
||
disappear after 3.0.</p>
|
||
<p><code>--show-each</code> This is an option for all wide modes
|
||
only: it displays all ciphers tested – not only succeeded ones.
|
||
<code>SHOW_EACH_C</code> is your friend if you prefer to set
|
||
this via the shell environment.</p>
|
||
<p><code>--color <0|1|2|3></code> determines the use of
|
||
colors on the screen and in the log file: <code>2</code> is the
|
||
default and makes use of ANSI and termcap escape codes on your
|
||
terminal. <code>1</code> just uses non-colored mark-up like
|
||
bold, italics, underline, reverse. <code>0</code> means no
|
||
mark-up at all = no escape codes. This is also what you want
|
||
when you want a log file without any escape codes.
|
||
<code>3</code> will color ciphers and EC according to an
|
||
internal (not yet perfect) rating. Setting the environment
|
||
variable <code>COLOR</code> to the value achieves the same
|
||
result. Please not that OpenBSD and early FreeBSD do not support
|
||
italics.</p>
|
||
<p><code>--colorblind</code> Swaps green and blue colors in the
|
||
output, so that this percentage of folks (up to 8% of males, see
|
||
https://en.wikipedia.org/wiki/Color_blindness) can distinguish
|
||
those findings better. <code>COLORBLIND</code> is the according
|
||
variable if you want to set this in the environment.</p>
|
||
<p><code>--debug <0-6></code> This gives you additional
|
||
output on the screen (2-6), only useful for debugging.
|
||
<code>DEBUG</code> is the according environment variable which
|
||
you can use. There are six levels (0 is the default, thus it has
|
||
no effect):</p>
|
||
<ol type="1">
|
||
<li>screen output normal but leaves useful debug output in
|
||
<strong>/tmp/testssl.XXXXXX/</strong> . The info about the exact
|
||
directory is included in the screen output in the end of the
|
||
run.</li>
|
||
<li>lists more what’s going on, status (high level) and
|
||
connection errors, a few general debug output</li>
|
||
<li>even slightly more info: hexdumps + other info</li>
|
||
<li>display bytes sent via sockets</li>
|
||
<li>display bytes received via sockets</li>
|
||
<li>whole 9 yards</li>
|
||
</ol>
|
||
<p><code>--disable-rating</code> disables rating. Rating
|
||
automatically gets disabled, to not give a wrong or misleading
|
||
grade, when not all required functions are executed (e.g when
|
||
checking for a single vulnerabilities).</p>
|
||
<h3 id="file-output-options">FILE OUTPUT OPTIONS</h3>
|
||
<p><code>--log, --logging</code> Logs stdout also to
|
||
<code>${NODE}-p${port}${YYYYMMDD-HHMM}.log</code> in current
|
||
working directory of the shell. Depending on the color output
|
||
option (see above) the output file will contain color and other
|
||
markup escape codes, unless you specify <code>--color 0</code>
|
||
too. <code>cat</code> and – if properly configured
|
||
<code>less</code> – will show the output properly formatted on
|
||
your terminal. The output shows a banner with the almost the
|
||
same information as on the screen. In addition it shows the
|
||
command line of the testssl.sh instance. Please note that the
|
||
resulting log file is formatted according to the width of your
|
||
screen while running testssl.sh. You can override the width with
|
||
the environment variable TERM_WIDTH.</p>
|
||
<p><code>--logfile <logfile></code> or
|
||
<code>-oL <logfile></code> Instead of the previous option
|
||
you may want to use this one if you want to log into a directory
|
||
or if you rather want to specify the log file name yourself. If
|
||
<code>logfile</code> is a directory the output will put into
|
||
<code>logfile/${NODE}-p${port}${YYYYMMDD-HHMM}.log</code>. If
|
||
<code>logfile</code> is a file it will use that file name, an
|
||
absolute path is also permitted here. LOGFILE is the variable
|
||
you need to set if you prefer to work environment variables
|
||
instead. Please note that the resulting log file is formatted
|
||
according to the width of your screen while running testssl.sh.
|
||
You can override the width with the environment variable
|
||
TERM_WIDTH.</p>
|
||
<p><code>--json</code> Logs additionally to JSON file
|
||
<code>${NODE}-p${port}${YYYYMMDD-HHMM}.json</code> in the
|
||
current working directory of the shell. The resulting JSON file
|
||
is opposed to <code>--json-pretty</code> flat – which means each
|
||
section is self contained and has an identifier for each single
|
||
check, the hostname/IP address, the port, severity and the
|
||
finding. For vulnerabilities it may contain a CVE and CWE entry
|
||
too. The output doesn’t contain a banner or a footer.</p>
|
||
<p><code>--jsonfile <jsonfile></code> or
|
||
<code>-oj <jsonfile></code> Instead of the previous option
|
||
you may want to use this one if you want to log the JSON out put
|
||
into a directory or if you rather want to specify the log file
|
||
name yourself. If <code>jsonfile</code> is a directory the
|
||
output will put into
|
||
<code>logfile/${NODE}-p${port}${YYYYMMDD-HHMM}.json</code>. If
|
||
<code>jsonfile</code> is a file it will use that file name, an
|
||
absolute path is also permitted here.</p>
|
||
<p><code>--json-pretty</code> Logs additionally to JSON file
|
||
<code>${NODE}-p${port}${YYYYMMDD-HHMM}.json</code> in the
|
||
current working directory of the shell. The resulting JSON file
|
||
is opposed to <code>--json</code> non-flat – which means it is
|
||
structured. The structure contains a header similar to the
|
||
banner on the screen, including the command line, scan host,
|
||
openssl binary used, testssl version and epoch of the start
|
||
time. Then for every test section of testssl.sh it contains a
|
||
separate JSON object/section. Each finding has a key/value pair
|
||
identifier with the identifier for each single check, the
|
||
severity and the finding. For vulnerabilities it may contain a
|
||
CVE and CWE entry too. The footer lists the scan time in
|
||
seconds.</p>
|
||
<p><code>--jsonfile-pretty <jsonfile></code> or
|
||
<code>-oJ <jsonfile></code> Similar to the aforementioned
|
||
<code>--jsonfile</code> or <code>--logfile</code> it logs the
|
||
output in pretty JSON format (see <code>--json-pretty</code>)
|
||
into a file or a directory. For further explanation see
|
||
<code>--jsonfile</code> or <code>--logfile</code>.</p>
|
||
<p><code>--csv</code> Logs additionally to a CSV file
|
||
<code>${NODE}-p${port}${YYYYMMDD-HHMM}.csv</code> in the current
|
||
working directory of the shell. The output contains a header
|
||
with the keys, the values are the same as in the flat JSON
|
||
format (identifier for each single check, the hostname/IP
|
||
address, the port, severity, the finding and for vulnerabilities
|
||
a CVE and CWE number).</p>
|
||
<p><code>--csvfile <csvfile></code> or
|
||
<code>-oC <csvfile></code> Similar to the aforementioned
|
||
<code>--jsonfile</code> or <code>--logfile</code> it logs the
|
||
output in CSV format (see <code>--cvs</code>) additionally into
|
||
a file or a directory. For further explanation see
|
||
<code>--jsonfile</code> or <code>--logfile</code>.</p>
|
||
<p><code>--html</code> Logs additionally to an HTML file
|
||
<code>${NODE}-p${port}${YYYYMMDD-HHMM}.html</code> in the
|
||
current working directory of the shell. It contains a 1:1 output
|
||
of the console. In former versions there was a non-native option
|
||
to use “aha” (Ansi HTML Adapter: github.com/theZiz/aha) like
|
||
<code>testssl.sh [options] <URI> | aha >output.html</code>.
|
||
This is not necessary anymore.</p>
|
||
<p><code>--htmlfile <htmlfile></code> or
|
||
<code>-oH <htmlfile></code> Similar to the aforementioned
|
||
<code>--jsonfile</code> or <code>--logfile</code> it logs the
|
||
output in HTML format (see <code>--html</code>) additionally
|
||
into a file or a directory. For further explanation see
|
||
<code>--jsonfile</code> or <code>--logfile</code>.</p>
|
||
<p><code>-oA <filename></code> /
|
||
<code>--outFile <filename></code> Similar to nmap it does
|
||
a file output to all available file formats: LOG, JSON pretty,
|
||
CSV, HTML. If the filename supplied is equal <code>auto</code>
|
||
the filename is automatically generated using ‘<span
|
||
class="math inline"><em>N</em><em>O</em><em>D</em><em>E</em> − <em>p</em></span>{port}<span
|
||
class="math inline"><em>Y</em><em>Y</em><em>Y</em><em>Y</em><em>M</em><em>M</em><em>D</em><em>D</em> − <em>H</em><em>H</em><em>M</em><em>M</em>.</span>{EXT}’
|
||
with the according extension. If a directory is provided all
|
||
output files will put into
|
||
<code><filename>/${NODE}-p${port}${YYYYMMDD-HHMM}.{log,json,csv,html}</code>.</p>
|
||
<p><code>-oa <filename></code> /
|
||
<code>--outfile <filename></code> Does the same as the
|
||
previous option but uses flat JSON instead.</p>
|
||
<p><code>--hints</code> This option is not in use yet. This
|
||
option is meant to give hints how to fix a finding or at least a
|
||
help to improve something. GIVE_HINTS is the environment
|
||
variable for this.</p>
|
||
<p><code>--severity <severity></code> For CSV and both
|
||
JSON outputs this will only add findings to the output file if a
|
||
severity is equal or higher than the <code>severity</code> value
|
||
specified. Allowed are
|
||
<code><LOW|MEDIUM|HIGH|CRITICAL></code>. WARN is another
|
||
level which translates to a client-side scanning error or
|
||
problem. Thus you will always see them in a file if they
|
||
occur.</p>
|
||
<p><code>--append</code> Normally, if an output file already
|
||
exists and it has a file size greater zero, testssl.sh will
|
||
prompt you to manually remove the file and exit with an error.
|
||
<code>--append</code> however will append to this file, without
|
||
a header. The environment variable APPEND does the same. Be
|
||
careful using this switch/variable. A complementary option which
|
||
overwrites an existing file doesn’t exist per design.</p>
|
||
<p><code>--overwrite</code> Normally, if an output file already
|
||
exists and it has a file size greater zero, testssl.sh will not
|
||
allow you to overwrite this file. This option will do that
|
||
<strong>without any warning</strong>. The environment variable
|
||
OVERWRITE does the same. Be careful, you have been warned!</p>
|
||
<p><code>--outprefix <fname_prefix></code> Prepend output
|
||
filename prefix <fname_prefix> before <code>${NODE}-</code>. You
|
||
can use as well the environment variable FNAME_PREFIX. Using
|
||
this any output files will be named
|
||
<code><fname_prefix>-${NODE}-p${port}${YYYYMMDD-HHMM}.<format></code>
|
||
when no file name of the respective output option was specified.
|
||
If you do not like the separator ‘-’ you can as well supply a
|
||
<code><fname_prefix></code> ending in ‘.’, ’_’ or ‘,’. In
|
||
this case or if you already supplied ‘-’ no additional ‘-’ will
|
||
be appended to <code><fname_prefix></code>.</p>
|
||
<p>A few file output options can also be preset via environment
|
||
variables.</p>
|
||
<h3 id="color-ratings">COLOR RATINGS</h3>
|
||
<p>Testssl.sh makes use of (the eight) standard terminal colors.
|
||
The color scheme is as follows:</p>
|
||
<ul>
|
||
<li>light red: a critical finding</li>
|
||
<li>red: a high finding</li>
|
||
<li>brown: a medium finding</li>
|
||
<li>yellow: a low finding</li>
|
||
<li>green (blue if COLORBLIND is set): something which is either
|
||
in general a good thing or a negative result of a check which
|
||
otherwise results in a high finding</li>
|
||
<li>light green (light blue if COLORBLIND is set) : something
|
||
which is either in general a very good thing or a negative
|
||
result of a check which otherwise results in a critical
|
||
finding</li>
|
||
<li>no color at places where also a finding can be expected: a
|
||
finding on an info level</li>
|
||
<li>cyan: currently only used for <code>--show-each</code> or an
|
||
additional hint</li>
|
||
<li>magenta: signals a warning condition, e.g. either a local
|
||
lack of capabilities on the client side or another problem</li>
|
||
<li>light magenta: a fatal error which either requires strict
|
||
consent from the user to continue or a condition which leaves no
|
||
other choice for testssl.sh to quit</li>
|
||
</ul>
|
||
<p>What is labeled as “light” above appears as such on the
|
||
screen but is technically speaking “bold”. Besides
|
||
<code>--color=3</code> will color ciphers according to an
|
||
internal and rough rating.</p>
|
||
<p>Markup (without any color) is used in the following
|
||
manner:</p>
|
||
<ul>
|
||
<li>bold: for the name of the test</li>
|
||
<li>underline + bold: for the headline of each test section</li>
|
||
<li>underline: for a sub-headline</li>
|
||
<li>italics: for strings just reflecting a value read from the
|
||
server</li>
|
||
</ul>
|
||
<h3 id="tuning-via-env-variables-and-more-options">TUNING via
|
||
ENV variables and more options</h3>
|
||
<p>Except the environment variables mentioned above which can
|
||
replace command line options here a some which cannot be set
|
||
otherwise. Variables used for tuning are preset with reasonable
|
||
values. <em>There should be no reason to change them</em> unless
|
||
you use testssl.sh under special conditions.</p>
|
||
<ul>
|
||
<li>TERM_WIDTH is a variable which overrides the auto-determined
|
||
terminal width size. Setting this variable normally only makes
|
||
sense if you log the output to a file using the
|
||
<code>--log</code>, <code>--logfile</code> or <code>-oL</code>
|
||
option.</li>
|
||
<li>DEBUG_ALLINONE / SETX: when setting one of those to true
|
||
testssl.sh falls back to the standard bash behavior,
|
||
i.e. calling <code>bash -x testssl.sh</code> it displays the
|
||
bash debugging output not in an external file
|
||
<code>/tmp/testssl-<XX>.log</code></li>
|
||
<li>DEBUGTIME: Profiling option. When using bash’s debug mode
|
||
and when this is set to true, it generates a separate text file
|
||
with epoch times in <code>/tmp/testssl-<XX>.time</code>.
|
||
They need to be concatenated by
|
||
<code>paste /tmp/testssl-<XX>.{time,log}</code>
|
||
<!—</li>
|
||
<li>FAST_SOCKET</li>
|
||
<li>SHOW_SIGALGO</li>
|
||
<li>FAST –></li>
|
||
<li>EXPERIMENTAL=true is an option which is sometimes used in
|
||
the development process to make testing easier. In released
|
||
versions this has no effect.</li>
|
||
<li>ALL_CLIENTS=true runs a client simulation with <em>all</em>
|
||
(currently 126) clients when testing HTTP.</li>
|
||
<li>UNBRACKTD_IPV6: needs to be set to true for some old
|
||
versions of OpenSSL (like from Gentoo) which don’t support
|
||
[bracketed] IPv6 addresses</li>
|
||
<li>NO_ENGINE: if you have problems with garbled output
|
||
containing the word ‘engine’ you might want to set this to true.
|
||
It forces testssl.sh not try to configure openssl’s engine or a
|
||
non existing one from libressl</li>
|
||
<li>HEADER_MAXSLEEP: To wait how long before killing the process
|
||
to retrieve a service banner / HTTP header</li>
|
||
<li>MAX_WAITSOCK: It instructs testssl.sh to wait until the
|
||
specified time before declaring a socket connection dead. Don’t
|
||
change this unless you’re absolutely sure what you’re doing.
|
||
Value is in seconds.</li>
|
||
<li>CCS_MAX_WAITSOCK Is the similar to above but applies only to
|
||
the CCS handshakes, for both of the two the two CCS payload.
|
||
Don’t change this unless you’re absolutely sure what you’re
|
||
doing. Value is in seconds.</li>
|
||
<li>HEARTBLEED_MAX_WAITSOCK Is the similar to MAX_WAITSOCK but
|
||
applies only to the ServerHello after sending the Heartbleed
|
||
payload. Don’t change this unless you’re absolutely sure what
|
||
you’re doing. Value is in seconds.</li>
|
||
<li>MEASURE_TIME_FILE For seldom cases when you don’t want the
|
||
scan time to be included in the output you can set this to
|
||
false.</li>
|
||
<li>STARTTLS_SLEEP is per default set to 10 (seconds). That’s
|
||
the value testssl.sh waits for a string in the STARTTLS
|
||
handshake before giving up.</li>
|
||
<li>MAX_PARALLEL is the maximum number of tests to run in
|
||
parallel in parallel mass testing mode. The default value of 20
|
||
may be made larger on systems with faster processors.</li>
|
||
<li>MAX_WAIT_TEST is the maximum time (in seconds) to wait for a
|
||
single test in parallel mass testing mode to complete. The
|
||
default is 1200. <!—</li>
|
||
<li>USLEEP_SND</li>
|
||
<li>USLEEP_REC –></li>
|
||
<li>HSTS_MIN is preset to 179 (days). If you want warnings
|
||
sooner or later for HTTP Strict Transport Security you can
|
||
change this.</li>
|
||
<li>HPKP_MIN is preset to 30 (days). If you want warnings sooner
|
||
or later for HTTP Public Key Pinning you can change this</li>
|
||
<li>DAYS2WARN1 is the first threshold when you’ll be warning of
|
||
a certificate expiration of a host, preset to 60 (days). For
|
||
Let’s Encrypt this value will be divided internally by 2.</li>
|
||
<li>DAYS2WARN2 is the second threshold when you’ll be warning of
|
||
a certificate expiration of a host, preset to 30 (days). For
|
||
Let’s Encrypt this value will be divided internally by 2.</li>
|
||
<li>TESTSSL_INSTALL_DIR is the derived installation directory of
|
||
testssl.sh. Relatively to that the <code>bin</code> and
|
||
mandatory <code>etc</code> directory will be looked for.</li>
|
||
<li>CA_BUNDLES_PATH: If you have an own set of CA bundles or you
|
||
want to point testssl.sh to a specific location of a CA bundle,
|
||
you can use this variable to set the directory which testssl.sh
|
||
will use. Please note that it overrides completely the builtin
|
||
path of testssl.sh which means that you will only test against
|
||
the bundles you point to. Also you might want to use
|
||
<code>~/utils/create_ca_hashes.sh</code> to create the hashes
|
||
for HPKP.</li>
|
||
<li>MAX_SOCKET_FAIL: A number which tells testssl.sh how often a
|
||
TCP socket connection may fail before the program gives up and
|
||
terminates. The default is 2. You can increase it to a higher
|
||
value if you frequently see a message like <em>Fatal error:
|
||
repeated openssl s_client connect problem, doesn’t make sense to
|
||
continue</em>.</li>
|
||
<li>MAX_OSSL_FAIL: A number which tells testssl.sh how often an
|
||
OpenSSL s_client connect may fail before the program gives up
|
||
and terminates. The default is 2. You can increase it to a
|
||
higher value if you frequently see a message like <em>Fatal
|
||
error: repeated TCP connect problems, giving up</em>.</li>
|
||
<li>MAX_HEADER_FAIL: A number which tells testssl.sh how often a
|
||
HTTP GET request over OpenSSL may return an empty file before
|
||
the program gives up and terminates. The default is 3. Also here
|
||
you can increase the threshold when you spot messages like
|
||
<em>Fatal error: repeated HTTP header connect problems, doesn’t
|
||
make sense to continue</em>.</li>
|
||
<li>OPENSSL2 can be used to supply an alternative openssl
|
||
version. This only makes sense if you want to amend the supplied
|
||
version in <code>bin/</code> which lacks TLS 1.3 support with a
|
||
version which doesn not and is not in
|
||
<code>/usr/bin/openssl</code>.</li>
|
||
<li>OSSL_SHORTCUT should be set to false when you run
|
||
interactively and don’t want to switch automatically to
|
||
<code>/usr/bin/openssl</code> (<code>OPENSSL2</code>) if you
|
||
encounter a TLS 1.3-only host.</li>
|
||
</ul>
|
||
<h3 id="rating">RATING</h3>
|
||
<p>This program has a near-complete implementation of SSL Labs’s
|
||
‘<a
|
||
href="https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide">SSL
|
||
Server Rating Guide</a>’.</p>
|
||
<p>This is <em>not</em> a 100% reimplementation of the <a
|
||
href="https://www.ssllabs.com/ssltest/analyze.html">SSL Lab’s
|
||
SSL Server Test</a>, but an implementation of the above rating
|
||
specification, slight discrepancies may occur. Please note that
|
||
for now we stick to the SSL Labs rating as good as possible. We
|
||
are not responsible for their rating. Before filing issues
|
||
please inspect their Rating Guide.</p>
|
||
<p>Disclaimer: Having a good grade is <strong>NOT</strong>
|
||
necessarily equal to having good security! Don’t start a
|
||
competition for the best grade, at least not without monitoring
|
||
the client handshakes and not without adding a portion of good
|
||
sense to it. Please note STARTTLS always results in a grade cap
|
||
to T. Anything else would lead to a false sense of security. Use
|
||
TLS, see also RFC 8314. The security of STARTTLS is always
|
||
client determined, i.e. checking the certificate which for SMTP
|
||
port 25 is often enough not the case. Also with DANE or MTA-STS
|
||
no one can test on the server side whether a client makes use if
|
||
it.</p>
|
||
<p>As of writing, these checks are missing:</p>
|
||
<ul>
|
||
<li>GOLDENDOODLE - should be graded <strong>F</strong> if
|
||
vulnerable</li>
|
||
<li>Insecure renegotiation - should be graded <strong>F</strong>
|
||
if vulnerable</li>
|
||
<li>Padding oracle in AES-NI CBC MAC check (CVE-2016-2107) -
|
||
should be graded <strong>F</strong> if vulnerable</li>
|
||
<li>Sleeping POODLE - should be graded <strong>F</strong> if
|
||
vulnerable</li>
|
||
<li>Zero Length Padding Oracle (CVE-2019-1559) - should be
|
||
graded <strong>F</strong> if vulnerable</li>
|
||
<li>Zombie POODLE - should be graded <strong>F</strong> if
|
||
vulnerable</li>
|
||
<li>All remaining old Symantec PKI certificates are distrusted -
|
||
should be graded <strong>T</strong></li>
|
||
<li>Symantec certificates issued before June 2016 are distrusted
|
||
- should be graded <strong>T</strong></li>
|
||
<li>Anonymous key exchange - should give <strong>0</strong>
|
||
points in <code>set_key_str_score()</code></li>
|
||
<li>Exportable key exchange - should give <strong>40</strong>
|
||
points in <code>set_key_str_score()</code></li>
|
||
<li>Weak key (Debian OpenSSL Flaw) - should give
|
||
<strong>0</strong> points in
|
||
<code>set_key_str_score()</code></li>
|
||
</ul>
|
||
<h4 id="implementing-new-grades-caps-or--warnings">Implementing
|
||
new grades caps or -warnings</h4>
|
||
<p>To implement a new grading cap, simply call the
|
||
<code>set_grade_cap()</code> function, with the grade and a
|
||
reason:</p>
|
||
<div class="sourceCode" id="cb2"><pre
|
||
class="sourceCode bash"><code class="sourceCode bash"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="ex">set_grade_cap</span> <span class="st">"D"</span> <span class="st">"Vulnerable to documentation"</span></span></code></pre></div>
|
||
<p>To implement a new grade warning, simply call the
|
||
<code>set_grade_warning()</code> function, with a message:</p>
|
||
<div class="sourceCode" id="cb3"><pre
|
||
class="sourceCode bash"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">set_grade_warning</span> <span class="st">"Documentation is always right"</span></span></code></pre></div>
|
||
<h4
|
||
id="implementing-a-new-check-which-contains-grade-caps">Implementing
|
||
a new check which contains grade caps</h4>
|
||
<p>When implementing a new check (be it vulnerability or not)
|
||
that sets grade caps, the <code>set_rating_state()</code> has to
|
||
be updated (i.e. the <code>$do_mycheck</code> variable-name has
|
||
to be added to the loop, and <code>$nr_enabled</code>
|
||
if-statement has to be incremented)</p>
|
||
<p>The <code>set_rating_state()</code> automatically disables
|
||
rating, if all the required checks are <em>not</em> enabled.
|
||
This is to prevent giving out a misleading or wrong grade.</p>
|
||
<h4 id="implementing-a-new-revision">Implementing a new
|
||
revision</h4>
|
||
<p>When a new revision of the rating specification comes around,
|
||
the following has to be done:</p>
|
||
<ul>
|
||
<li>New grade caps has to be either:
|
||
<ol type="1">
|
||
<li>Added to the script wherever relevant, or</li>
|
||
<li>Added to the above list of missing checks (if above is not
|
||
possible)</li>
|
||
</ol></li>
|
||
<li>New grade warnings has to be added wherever relevant</li>
|
||
<li>The revision output in <code>run_rating()</code> function
|
||
has to updated</li>
|
||
</ul>
|
||
<h2 id="examples">EXAMPLES</h2>
|
||
<pre><code> testssl.sh testssl.sh</code></pre>
|
||
<p>does a default run on https://testssl.sh (protocols, standard
|
||
cipher lists, server’s cipher preferences, forward secrecy,
|
||
server defaults, vulnerabilities, client simulation, and
|
||
rating.</p>
|
||
<pre><code> testssl.sh testssl.net:443</code></pre>
|
||
<p>does the same default run as above with the subtle difference
|
||
that testssl.net has two IPv4 addresses. Both are tested.</p>
|
||
<pre><code> testssl.sh --ip=one --wide https://testssl.net:443</code></pre>
|
||
<p>does the same checks as above, with the difference that one
|
||
IP address is being picked randomly. Displayed is everything
|
||
where possible in wide format.</p>
|
||
<pre><code> testssl.sh -6 https://testssl.net</code></pre>
|
||
<p>As opposed to the first example it also tests the IPv6 part –
|
||
supposed you have an IPv6 network and your openssl supports IPv6
|
||
(see above).</p>
|
||
<pre><code> testssl.sh -t smtp smtp.gmail.com:25</code></pre>
|
||
<p>Checks are done via a STARTTLS handshake on the plain text
|
||
port 25. It checks every IP on smtp.gmail.com.</p>
|
||
<pre><code> testssl.sh --starttls=imap imap.gmx.net:143</code></pre>
|
||
<p>does the same on the plain text IMAP port.</p>
|
||
<p>Please note that for plain TLS-encrypted ports you must not
|
||
specify the protocol option when no STARTTLS handshake is
|
||
offered: <code>testssl.sh smtp.gmail.com:465</code> just checks
|
||
the encryption on the SMTPS port,
|
||
<code>testssl.sh imap.gmx.net:993</code> on the IMAPS port. Also
|
||
MongoDB which provides TLS support without STARTTLS can be
|
||
tested directly.</p>
|
||
<h2 id="rfcs-and-other-standards">RFCs and other standards</h2>
|
||
<ul>
|
||
<li>RFC 2246: The TLS Protocol Version 1.0</li>
|
||
<li>RFC 2595: Using TLS with IMAP, POP3 and ACAP</li>
|
||
<li>RFC 2817: Upgrading to TLS Within HTTP/1.1</li>
|
||
<li>RFC 2818: HTTP Over TLS</li>
|
||
<li>RFC 2830: Lightweight Directory Access Protocol (v3):
|
||
Extension for Transport Layer Security</li>
|
||
<li>RFC 3207: SMTP Service Extension for Secure SMTP over
|
||
Transport Layer Security</li>
|
||
<li>RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
||
4rev1</li>
|
||
<li>RFC 4346: The Transport Layer Security (TLS) Protocol
|
||
Version 1.1</li>
|
||
<li>RFC 4366: Transport Layer Security (TLS) Extensions</li>
|
||
<li>RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
|
||
for Transport Layer Security (TLS)</li>
|
||
<li>RFC 5077: Transport Layer Security (TLS) Session
|
||
Resumption</li>
|
||
<li>RFC 5246: The Transport Layer Security (TLS) Protocol
|
||
Version 1.2</li>
|
||
<li>RFC 5280: Internet X.509 Public Key Infrastructure
|
||
Certificate and Certificate Revocation List (CRL) Profile</li>
|
||
<li>RFC 5321: Simple Mail Transfer Protocol</li>
|
||
<li>RFC 5746: Transport Layer Security (TLS) Renegotiation
|
||
Indication Extension</li>
|
||
<li>RFC 5804: A Protocol for Remotely Managing Sieve
|
||
Scripts</li>
|
||
<li>RFC 6066: Transport Layer Security (TLS) Extensions:
|
||
Extension Definitions</li>
|
||
<li>RFC 6101: The Secure Sockets Layer (SSL) Protocol Version
|
||
3.0</li>
|
||
<li>RFC 6120: Extensible Messaging and Presence Protocol (XMPP):
|
||
Core</li>
|
||
<li>RFC 6125: Domain-Based Application Service Identity
|
||
[..]</li>
|
||
<li>RFC 6797: HTTP Strict Transport Security (HSTS)</li>
|
||
<li>RFC 6961: The Transport Layer Security (TLS) Multiple
|
||
Certificate Status Request Extension</li>
|
||
<li>RFC 7469: Public Key Pinning Extension for HTTP (HPKP)</li>
|
||
<li>RFC 7507: TLS Fallback Signaling Cipher Suite Value (SCSV)
|
||
for Preventing Protocol Downgrade Attacks</li>
|
||
<li>RFC 7627: Transport Layer Security (TLS) Session Hash and
|
||
Extended Master Secret Extension</li>
|
||
<li>RFC 7633: X.509v3 Transport Layer Security (TLS) Feature
|
||
Extension</li>
|
||
<li>RFC 7465: Prohibiting RC4 Cipher Suites</li>
|
||
<li>RFC 7685: A Transport Layer Security (TLS) ClientHello
|
||
Padding Extension</li>
|
||
<li>RFC 7905: ChaCha20-Poly1305 Cipher Suites for Transport
|
||
Layer Security (TLS)</li>
|
||
<li>RFC 7919: Negotiated Finite Field Diffie-Hellman Ephemeral
|
||
Parameters for Transport Layer Security</li>
|
||
<li>RFC 8143: Using Transport Layer Security (TLS) with Network
|
||
News Transfer Protocol (NNTP)</li>
|
||
<li>RFC 8446: The Transport Layer Security (TLS) Protocol
|
||
Version 1.3</li>
|
||
<li>RFC 8470: Using Early Data in HTTP</li>
|
||
<li>RFC 8701: Applying Generate Random Extensions And Sustain
|
||
Extensibility (GREASE) to TLS Extensibility</li>
|
||
<li>RFC 9000: QUIC: A UDP-Based Multiplexed and Secure
|
||
Transport</li>
|
||
<li>W3C CSP: Content Security Policy Level 1-3</li>
|
||
<li>TLSWG Draft: The Transport Layer Security (TLS) Protocol
|
||
Version 1.3</li>
|
||
<li>FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism
|
||
Standard</li>
|
||
</ul>
|
||
<p><a
|
||
href="ihttps://www.rfc-editor.org/search/rfc_search_detail.php?title=TLS&page=All">More
|
||
RFCs</a> might be applicable.</p>
|
||
<h2 id="exit-status">EXIT STATUS</h2>
|
||
<ul>
|
||
<li>0 testssl.sh finished successfully without errors and
|
||
without ambiguous results</li>
|
||
<li>1 testssl.sh has encountered exactly one ambiguous situation
|
||
or an error during run</li>
|
||
<li>1+n same as previous. The errors or ambiguous results are
|
||
added, also per IP.</li>
|
||
<li>50-200 reserved for returning a vulnerability scoring for
|
||
system monitoring or a CI tools</li>
|
||
<li>242 (ERR_CHILD) Child received a signal from master</li>
|
||
<li>244 (ERR_RESOURCE) Resources testssl.sh needs couldn’t be
|
||
read</li>
|
||
<li>245 (ERR_CLUELESS) Weird state, either though user options
|
||
or testssl.sh</li>
|
||
<li>246 (ERR_CONNECT) Connectivity problem</li>
|
||
<li>247 (ERR_DNSLOOKUP) Problem with resolving IP addresses or
|
||
names</li>
|
||
<li>248 (ERR_OTHERCLIENT) Other client problem</li>
|
||
<li>249 (ERR_DNSBIN) Problem with DNS lookup binaries</li>
|
||
<li>250 (ERR_OSSLBIN) Problem with OpenSSL binary</li>
|
||
<li>251 (ERR_NOSUPPORT) Feature requested is not supported</li>
|
||
<li>252 (ERR_FNAMEPARSE) Input file couldn’t be parsed</li>
|
||
<li>253 (ERR_FCREATE) Output file couldn’t be created</li>
|
||
<li>254 (ERR_CMDLINE) Cmd line couldn’t be parsed</li>
|
||
<li>255 (ERR_BASH) Bash version incorrect</li>
|
||
</ul>
|
||
<h2 id="files">FILES</h2>
|
||
<p><strong>etc/*pem</strong> are the certificate stores from
|
||
Apple, Linux, Mozilla Firefox, Windows and Java.</p>
|
||
<p><strong>etc/client-simulation.txt</strong> contains client
|
||
simulation data.</p>
|
||
<p><strong>etc/cipher-mapping.txt</strong> provides a mandatory
|
||
file with mapping from OpenSSL cipher suites names to the ones
|
||
from IANA / used in the RFCs.</p>
|
||
<p><strong>etc/tls_data.txt</strong> provides a mandatory file
|
||
for ciphers (bash sockets) and key material.</p>
|
||
<h2 id="authors">AUTHORS</h2>
|
||
<p>Developed by Dirk Wetter, David Cooper and many others, see
|
||
CREDITS.md .</p>
|
||
<h2 id="copyright">COPYRIGHT</h2>
|
||
<p>Copyright © 2012 Dirk Wetter. License GPLv2: Free Software
|
||
Foundation, Inc. This is free software: you are free to change
|
||
and redistribute it under the terms of the license, see
|
||
LICENSE.</p>
|
||
<p>Attribution is important for the future of this project -
|
||
also in the internet. Thus if you’re offering a scanner based on
|
||
testssl.sh as a public and/or paid service in the internet you
|
||
are strongly encouraged to mention to your audience that you’re
|
||
using this program and where to get this program from. That
|
||
helps us to get bugfixes, other feedback and more
|
||
contributions.</p>
|
||
<p>Usage WITHOUT ANY WARRANTY. USE at your OWN RISK!</p>
|
||
<h2 id="limitation">LIMITATION</h2>
|
||
<p>All native Windows platforms emulating Linux are known to be
|
||
slow.</p>
|
||
<h2 id="bugs">BUGS</h2>
|
||
<p>Probably. Current known ones and interface for filing new
|
||
ones: https://testssl.sh/bugs/ .</p>
|
||
<h2 id="see-also">SEE ALSO</h2>
|
||
<p><code>ciphers</code>(1), <code>openssl</code>(1),
|
||
<code>s_client</code>(1), <code>x509</code>(1),
|
||
<code>verify</code>(1), <code>ocsp</code>(1),
|
||
<code>crl</code>(1), <code>bash</code>(1) and the websites
|
||
https://testssl.sh/ and https://github.com/testssl/testssl.sh/
|
||
.</p>
|
||
</body>
|
||
</html>
|