mirror of
https://github.com/drwetter/testssl.sh.git
synced 2025-10-31 05:45:26 +01:00
e29b1f40e6
The HTML manual is now post processed through tidy which removes the problem of ">" not HTML encoded. --color 0 is now explicitly mentioned to avoid escaped codes in the output. Minor changes wrt certificate stores
802 lines
55 KiB
HTML
802 lines
55 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy for Linux (vers 25 March 2009), see www.w3.org">
|
|
<meta http-equiv='content-type' value='text/html;charset=utf8'>
|
|
<meta name='generator' value='Ronn/v0.7.3 (http://github.com/rtomayko/ronn/tree/0.7.3)'>
|
|
<title>testssl(1)</title>
|
|
|
|
<style type='text/css' media='all'>
|
|
/* style: man */
|
|
body#manpage {margin:0}
|
|
.mp {padding:0 9ex 1ex 4ex}
|
|
.mp p,.mp pre,.mp ul,.mp ol,.mp dl {margin:0 0 20px 0}
|
|
.mp h2 {margin:10px 0 0 0}
|
|
.mp > p,.mp > pre,.mp > ul,.mp > ol,.mp > dl {margin-left:8ex}
|
|
.mp h3 {margin:0 0 0 4ex}
|
|
.mp dt {margin:0;clear:left}
|
|
.mp dt.flush {float:left;width:8ex}
|
|
.mp dd {margin:0 0 0 9ex}
|
|
.mp h1,.mp h2,.mp h3,.mp h4 {clear:left}
|
|
.mp pre {margin-bottom:20px}
|
|
.mp pre+h2,.mp pre+h3 {margin-top:22px}
|
|
.mp h2+pre,.mp h3+pre {margin-top:5px}
|
|
.mp img {display:block;margin:auto}
|
|
.mp h1.man-title {display:none}
|
|
.mp,.mp code,.mp pre,.mp tt,.mp kbd,.mp samp,.mp h3,.mp h4 {font-family:monospace;font-size:14px;line-height:1.42857142857143}
|
|
.mp h2 {font-size:16px;line-height:1.25}
|
|
.mp h1 {font-size:20px;line-height:2}
|
|
.mp {text-align:justify;background:#fff}
|
|
.mp,.mp code,.mp pre,.mp pre code,.mp tt,.mp kbd,.mp samp {color:#131211}
|
|
.mp h1,.mp h2,.mp h3,.mp h4 {color:#030201}
|
|
.mp u {text-decoration:underline}
|
|
.mp code,.mp strong,.mp b {font-weight:bold;color:#131211}
|
|
.mp em,.mp var {font-style:italic;color:#232221;text-decoration:none}
|
|
.mp a,.mp a:link,.mp a:hover,.mp a code,.mp a pre,.mp a tt,.mp a kbd,.mp a samp {color:#0000ff}
|
|
.mp b.man-ref {font-weight:normal;color:#434241}
|
|
.mp pre {padding:0 4ex}
|
|
.mp pre code {font-weight:normal;color:#434241}
|
|
.mp h2+pre,h3+pre {padding-left:0}
|
|
ol.man-decor,ol.man-decor li {margin:3px 0 10px 0;padding:0;float:left;width:33%;list-style-type:none;text-transform:uppercase;color:#999;letter-spacing:1px}
|
|
ol.man-decor {width:100%}
|
|
ol.man-decor li.tl {text-align:left}
|
|
ol.man-decor li.tc {text-align:center;letter-spacing:4px}
|
|
ol.man-decor li.tr {text-align:right;float:right}
|
|
</style>
|
|
</head>
|
|
<!--
|
|
The following styles are deprecated and will be removed at some point:
|
|
div#man, div#man ol.man, div#man ol.head, div#man ol.man.
|
|
|
|
The .man-page, .man-decor, .man-head, .man-foot, .man-title, and
|
|
.man-navigation should be used instead.
|
|
-->
|
|
<body id='manpage'>
|
|
<div class='mp' id='man'>
|
|
<div class='man-navigation' style='display:none'><a href="#NAME">NAME</a> <a href="#NAME">NAME</a>
|
|
<a href="#SYNOPSIS">SYNOPSIS</a> <a href="#DESCRIPTION">DESCRIPTION</a> <a href=
|
|
"#REQUIREMENTS">REQUIREMENTS</a> <a href="#GENERAL">GENERAL</a> <a href=
|
|
"#OPTIONS-AND-PARAMETERS">OPTIONS AND PARAMETERS</a> <a href="#EXAMPLES">EXAMPLES</a> <a href=
|
|
"#RFCs-and-other-standards">RFCs and other standards</a> <a href="#EXIT-STATUS">EXIT STATUS</a>
|
|
<a href="#FILES">FILES</a> <a href="#AUTHORS">AUTHORS</a> <a href="#COPYRIGHT">COPYRIGHT</a>
|
|
<a href="#LIMITATION">LIMITATION</a> <a href="#BUGS">BUGS</a> <a href="#SEE-ALSO">SEE
|
|
ALSO</a></div>
|
|
<ol class='man-decor man-head man head'>
|
|
<li class='tl'>testssl(1)</li>
|
|
<li class='tr'>testssl(1)</li>
|
|
</ol>
|
|
<h2 id="NAME">NAME</h2>
|
|
<p class="man-name"><code>testssl</code></p>
|
|
<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>
|
|
<p>0) 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>
|
|
<p>1) SSL/TLS protocol check</p>
|
|
<p>2) standard cipher categories to give you upfront an idea for the ciphers supported</p>
|
|
<p>3) checks (perfect) forward secrecy: ciphers and elliptical curves</p>
|
|
<p>4) server preferences (server order)</p>
|
|
<p>5) server defaults (certificate info, TLS extensions, session information)</p>
|
|
<p>6) HTTP header (if HTTP detected or being forced via <code>--assume-http</code>)</p>
|
|
<p>7) vulnerabilities</p>
|
|
<p>8) testing each of 370 preconfigured ciphers</p>
|
|
<p>9) client simulation</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">BANNER OPTIONS</h3>
|
|
<p><code>--help</code> (or no arg) display 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.</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>. 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>
|
|
<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>telnet</code>,
|
|
<code>ldap</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.</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.</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. The hostname supplied
|
|
will be resolved to the first A record. 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. Proxying via IPv6 addresses is not possible, no HTTPS or SOCKS proxy is
|
|
supported.</p>
|
|
<p><code>-6</code> does (also) IPv6 checks. Please note that testssl.sh doesn't perform checks on
|
|
an IPv6 address automatically, because of two reasons: testssl.sh does no connectivity checks for
|
|
IPv6 and it cannot determine reliably whether the OpenSSL binary you're using has IPv6 s_client
|
|
support. <code>-6</code> assumes both is the case. If both conditions are met and you in general
|
|
prefer to test for IPv6 branches as well you can add <code>HAS_IPv6</code> to your shell
|
|
environment. 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.</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 at the moment 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. This option is only
|
|
recommended 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 very hard to find automagically
|
|
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>).</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 enviroment variable for this.</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>--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) for trust chain checks.
|
|
<code>cafile</code> can be a single path or multiple paths as a comma separated list of root CA
|
|
files. Internally they will be added during runtime to all CA stores. This is (only) useful for
|
|
internal hosts whose certificates is issued by internal CAs. Alternatively ADDITIONAL_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, --standard</code> tests certain lists of cipher suites by strength. 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' * <code>LOW</code>
|
|
(64 Bit + DES ciphers, without EXPORT ciphers): 'LOW:DES:!ADH:!EXP:!NULL'</li>
|
|
<li><code>Weak 128 Bit ciphers</code>: 'MEDIUM:!aNULL:!AES:!CAMELLIA:!ARIA:!CHACHA20:!3DES'</li>
|
|
<li><code>3DES Ciphers</code>: '3DES:!aNULL:!ADH'</li>
|
|
<li><code>High grade Ciphers</code>:
|
|
'HIGH:!NULL:!aNULL:!DES:!3DES:!AESGCM:!CHACHA20:!AESGCM:!CamelliaGCM:!AESCCM8:!AESCCM'</li>
|
|
<li><code>Strong grade Ciphers</code> (AEAD):
|
|
'AESGCM:CHACHA20:AESGCM:CamelliaGCM:AESCCM8:AESCCM'</li>
|
|
</ul>
|
|
<p><code>-f, --pfs, --fs,--nsa</code> Checks robust (perfect) 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 TLS/SSL protocols SSLv2, SSLv3, TLS 1.0 through TLS 1.3 and
|
|
for HTTP: SPDY (NPN) and ALPN, a.k.a. HTTP/2. For TLS 1.3 several drafts (from 18 on) and final are
|
|
supported and being tested for.</p>
|
|
<p><code>-P, --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): available TLS
|
|
extensions, TLS ticket + session information/capabilities, session resumption capabilities, time
|
|
skew relative to localhost (most server implementations return random values) and several
|
|
certificate info: certificate signature algorithm, certificate key size, X509v3 key usage and
|
|
extended key usage, certificate fingerprints and serial, revocation info (CRL, OCSP, OCSP
|
|
stapling/must staple), certificate transparency info (if provided by server). When
|
|
<code>--phone-out</code> supplied it checks against the certificate issuer whether the host
|
|
certificate has been revoked. This section also displays certificate start and expiration time in
|
|
GMT. In addition it checks the trust (CN, SAN, chain of trust). For the trust chain check there are
|
|
5 certificate stores 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 ADDITIONAL_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 multiple server
|
|
certificates are being checked for as well as the certificate reply to a non-SNI (Server Name
|
|
Indication) client hello to the IP address. Also the Certification Authority Authorization (CAA)
|
|
record is displayed and whether "Certificate Transparency" (CT) is supported (and if: how). TLS
|
|
clock skew matches 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 https://www.ietf.org/archive/id/draft-ietf-tls-grease-01.txt . This
|
|
checks doesn't run per default.</p>
|
|
<h3 id="VULNERABILITIES">VULNERABILITIES</h3>
|
|
<p><code>-U, --vulnerable</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 vulnerabilty 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>-BB, --robot</code> Checks for vulnerability to ROBOT / (<em>Return Of Bleichenbacher's
|
|
Oracle Threat</em>) attack.</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>-4, --rc4, --appelbaum</code> Checks which RC4 stream ciphers are being offered.</p>
|
|
<h3 id="OUTPUT-OPTIONS">OUTPUT OPTIONS</h3>
|
|
<p><code>--warnings <batch|off|false></code> The warnings parameter determines how testssl.sh
|
|
will deal with situations where user input normally will be necessary. There are a couple of
|
|
options here. <code>batch</code> doesn't wait for a confirming keypress. This is automatically
|
|
being chosen for mass testing (<code>--file</code>). <code>-false</code> just skips the warning AND
|
|
the confirmation. 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 as a best guess by testssl.sh. The same can be achieved by setting
|
|
the environment variable <code>WARNINGS</code>.</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.</p>
|
|
<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, PFS, 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> It determines the use of colors on the screen:
|
|
<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.</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>
|
|
<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>
|
|
<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.
|
|
If</code>jsonfile` 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 in the current working directory of the shell. The
|
|
resulting JSON file is opposed to</code>--json` 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>--html 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
|
|
'${NODE}-p${port}${YYYYMMDD-HHMM}.${EXT}' with the according extension.</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 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>--outprefix <fname_prefix></code> Prepend output filename prefix
|
|
<var>fname_prefix</var> before '${NODE}-'. 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>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>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 incerase the threshold when you spot messages like <em>Fatal error: repeated HTTP header
|
|
connect problems, doesn't make sense to continue</em>.</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, PFS, server
|
|
preferences, server defaults, vulnerabilities, testing all known 370 ciphers, client
|
|
simulation.</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 2818: HTTP Over TLS</li>
|
|
<li>RFC 2595: Using TLS with IMAP, POP3 and ACAP</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 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>W3C CSP: Content Security Policy Level 1-3</li>
|
|
<li>TLSWG Draft: The Transport Layer Security (TLS) Protocol Version 1.3</li>
|
|
</ul>
|
|
<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. Usage WITHOUT
|
|
ANY WARRANTY. USE at your OWN RISK!</p>
|
|
<p>If you're offering testssl.sh as a public and / or paid service in the internet you need to
|
|
mention to your audience that you're using this program and where to get this program from.</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 <strong>https://testssl.sh/</strong> and
|
|
<strong>https://github.com/drwetter/testssl.sh/</strong> .</p>
|
|
<ol class='man-decor man-foot man foot'>
|
|
<li class='tc'>January 2019</li>
|
|
<li class='tr'>testssl(1)</li>
|
|
</ol>
|
|
</div>
|
|
</body>
|
|
</html>
|