neulab/tldr huggingface dataset:
-h ,  -? ,  --help Prints the usage for the interpreter executable and exits.
-i     When a script is passed as first argument or the -c option is used, enter interactive mode after executing the script or the command.  It does not read the $PYTHONSTARTUP file.  This can be useful to inspect global variables or a stack trace when a script raises an exception.
-I     Run Python in isolated mode. This also implies -E and -s. In isolated mode sys.path contains neither the script's directory nor the user's site-packages directory. All PYTHON* environment variables are ignored, too.  Further restrictions may be imposed to prevent the user from injecting malicious code.
-m module-name Searches sys.path for the named module and runs the corresponding .py file as a script.
-O     Remove assert statements and any code conditional on the value of __debug__; augment the filename for compiled (bytecode) files by adding .opt-1 before the .pyc extension.
-OO    Do -O and also discard docstrings; change the filename for compiled (bytecode) files by adding .opt-2 before the .pyc extension.
-q     Do not print the version and copyright messages. These messages are also suppressed in non-interactive mode.
-s     Don't add user site directory to sys.path.
-S     Disable the import of the module site and the site-dependent manipulations of sys.path that it entails.  Also disable these manipulations if site is explicitly imported later.
-u     Force the stdout and stderr streams to be unbuffered.  This option has no effect on the stdin stream.
-v     Print a message each time a module is initialized, showing the place (filename or built-in module) from which it is loaded.  When given twice, print a message for each file that is checked for when searching for a module.  Also provides information on module cleanup at exit.
-V ,  --version Prints the Python version number of the executable and exits. When given twice, print more information about the build.
-W argument Warning control.  Python sometimes prints warning message to sys.stderr.  A typical warning message has the following form: file:line: category: message.  By default, each warning is printed once for each source line where it occurs.  This option controls how often warnings are printed.  Multiple -W options may be given; when a warning matches more than one option, the action for the last matching option is performed.  Invalid -W options are ignored (a warning message is printed about invalid options when the first warning is issued).  Warnings can also be controlled from within a Python program using the warnings module.
The simplest form of argument is one of the following action strings (or a unique abbreviation): ignore to ignore all warnings; default to explicitly request the default behavior (printing each warning once per source line); all to print a warning each time it occurs (this may generate many messages if a warning is triggered repeatedly for the same source line, such as inside a loop); module to print each warning only the first time it occurs in each module; once to print each warning only the first time it occurs in the program; or error to raise an exception instead of printing a warning message.
The full form of argument is action:message:category:module:line. Here, action is as explained above but only applies to messages that match the remaining fields.  Empty fields match all values; trailing empty fields may be omitted.  The message field matches the start of the warning message printed; this match is case- insensitive.  The category field matches the warning category. This must be a class name; the match test whether the actual warning category of the message is a subclass of the specified warning category.  The full class name must be given.  The module field matches the (fully-qualified) module name; this match is case-sensitive.  The line field matches the line number, where zero matches all line numbers and is thus equivalent to an omitted line number.
-X option Set implementation specific option. The following options are available:
-X faulthandler: enable faulthandler
-X showrefcount: output the total reference count and number of used memory blocks when the program finishes or after each statement in the interactive interpreter. This only works on debug builds
-X tracemalloc: start tracing Python memory allocations using the tracemalloc module. By default, only the most recent frame is stored in a traceback of a trace. Use -X tracemalloc=NFRAME to start tracing with a traceback limit of NFRAME frames
-X importtime: show how long each import takes. It shows module name, cumulative time (including nested imports) and self time (excluding nested imports). Note that its output may be broken in multi-threaded application. Typical usage is python3 -X importtime -c 'import asyncio'
-X dev: enable CPython's "development mode", introducing additional runtime checks which are too expensive to be enabled by default. It will not be more verbose than the default if the code is correct: new warnings are only emitted when an issue is detected. Effect of the developer mode: * Add default warning filter, as -W default * Install debug hooks on memory allocators: see the PyMem_SetupDebugHooks() C function * Enable the faulthandler module to dump the Python traceback on a crash * Enable asyncio debug mode * Set the dev_mode attribute of sys.flags to True * io.IOBase destructor logs close() exceptions
-X utf8: enable UTF-8 mode for operating system interfaces, overriding the default locale-aware mode. -X utf8=0 explicitly disables UTF-8 mode (even when it would otherwise activate automatically). See PYTHONUTF8 for more details
-X pycache_prefix=PATH: enable writing .pyc files to a parallel tree rooted at the given directory instead of to the code tree.
-x     Skip the first line of the source.  This is intended for a DOS specific hack only.  Warning: the line numbers in error messages will be off by one!
The interpreter interface resembles that of the UNIX shell: when called with standard input connected to a tty device, it prompts for commands and executes them until an EOF is read; when called with a file name argument or with a file as standard input, it reads and executes a script from that file; when called with -c command, it executes the Python statement(s) given as command.  Here command may contain multiple statements separated by newlines.  Leading whitespace is significant in Python statements!  In non-interactive mode, the entire input is parsed before it is executed.
If available, the script name and additional arguments thereafter are passed to the script in the Python variable sys.argv, which is a list of strings (you must first import sys to be able to access it).  If no script name is given, sys.argv[0] is an empty string; if -c is used, sys.argv[0] contains the string '-c'.  Note that options interpreted by the Python interpreter itself are not placed in sys.argv.
In interactive mode, the primary prompt is `>>>'; the second prompt (which appears when a command is not complete) is `...'.  The prompts can be changed by assignment to sys.ps1 or sys.ps2.  The interpreter quits when it reads an EOF at a prompt.  When an unhandled exception occurs, a stack trace is printed and control returns to the primary prompt; in non- interactive mode, the interpreter exits after printing the stack trace. The interrupt signal raises the KeyboardInterrupt exception; other UNIX signals are not caught (except that SIGPIPE is sometimes ignored, in favor of the IOError exception).  Error messages are written to stderr.
These are subject to difference depending on local installation conventions; ${prefix} and ${exec_prefix} are installation-dependent and should be interpreted as for GNU software; they may be the same.  The default for both is /usr/local.
${exec_prefix}/bin/python Recommended location of the interpreter.
${prefix}/lib/python<version> ${exec_prefix}/lib/python<version> Recommended locations of the directories containing the standard modules.
${prefix}/include/python<version> ${exec_prefix}/include/python<version> Recommended locations of the directories containing the include files needed for developing Python extensions and embedding the interpreter.
PYTHONHOME Change the location of the standard Python libraries.  By default, the libraries are searched in ${prefix}/lib/python<version> and ${exec_prefix}/lib/python<version>, where ${prefix} and ${exec_prefix} are installation-dependent directories, both defaulting to /usr/local.  When $PYTHONHOME is set to a single directory, its value replaces both ${prefix} and ${exec_prefix}. To specify different values for these, set $PYTHONHOME to ${prefix}:${exec_prefix}.
PYTHONPATH Augments the default search path for module files.  The format is the same as the shell's $PATH: one or more directory pathnames separated by colons.  Non-existent directories are silently ignored.  The default search path is installation dependent, but generally begins with ${prefix}/lib/python<version> (see PYTHONHOME above).  The default search path is always appended to $PYTHONPATH.  If a script argument is given, the directory containing the script is inserted in the path in front of $PYTHONPATH.  The search path can be manipulated from within a Python program as the variable sys.path.
PYTHONPLATLIBDIR Override sys.platlibdir.
PYTHONSTARTUP If this is the name of a readable file, the Python commands in that file are executed before the first prompt is displayed in interactive mode.  The file is executed in the same name space where interactive commands are executed so that objects defined or imported in it can be used without qualification in the interactive session.  You can also change the prompts sys.ps1 and sys.ps2 in this file.
PYTHONOPTIMIZE If this is set to a non-empty string it is equivalent to specifying the -O option. If set to an integer, it is equivalent to specifying -O multiple times.
PYTHONDEBUG If this is set to a non-empty string it is equivalent to specifying the -d option. If set to an integer, it is equivalent to specifying -d multiple times.
PYTHONDONTWRITEBYTECODE If this is set to a non-empty string it is equivalent to specifying the -B option (don't try to write .pyc files).
PYTHONINSPECT If this is set to a non-empty string it is equivalent to specifying the -i option.
PYTHONIOENCODING If this is set before running the interpreter, it overrides the encoding used for stdin/stdout/stderr, in the syntax encodingname:errorhandler The errorhandler part is optional and has the same meaning as in str.encode. For stderr, the errorhandler part is ignored; the handler will always be ´backslashreplace´.
PYTHONNOUSERSITE If this is set to a non-empty string it is equivalent to specifying the -s option (Don't add the user site directory to sys.path).
PYTHONUNBUFFERED If this is set to a non-empty string it is equivalent to specifying the -u option.
PYTHONVERBOSE If this is set to a non-empty string it is equivalent to specifying the -v option. If set to an integer, it is equivalent to specifying -v multiple times.
PYTHONWARNINGS If this is set to a comma-separated string it is equivalent to specifying the -W option for each separate value.
PYTHONHASHSEED If this variable is set to "random", a random value is used to seed the hashes of str and bytes objects.
If PYTHONHASHSEED is set to an integer value, it is used as a fixed seed for generating the hash() of the types covered by the hash randomization.  Its purpose is to allow repeatable hashing, such as for selftests for the interpreter itself, or to allow a cluster of python processes to share hash values.
The integer must be a decimal number in the range [0,4294967295]. Specifying the value 0 will disable hash randomization.
PYTHONMALLOC Set the Python memory allocators and/or install debug hooks. The available memory allocators are malloc and pymalloc.  The available debug hooks are debug, malloc_debug, and pymalloc_debug.
When Python is compiled in debug mode, the default is pymalloc_debug and the debug hooks are automatically used. Otherwise, the default is pymalloc.
PYTHONMALLOCSTATS If set to a non-empty string, Python will print statistics of the pymalloc memory allocator every time a new pymalloc object arena is created, and on shutdown.
This variable is ignored if the $PYTHONMALLOC environment variable is used to force the malloc(3) allocator of the C library, or if Python is configured without pymalloc support.
PYTHONASYNCIODEBUG If this environment variable is set to a non-empty string, enable the debug mode of the asyncio module.
PYTHONTRACEMALLOC If this environment variable is set to a non-empty string, start tracing Python memory allocations using the tracemalloc module.
The value of the variable is the maximum number of frames stored in a traceback of a trace. For example, PYTHONTRACEMALLOC=1 stores only the most recent frame.
PYTHONFAULTHANDLER If this environment variable is set to a non-empty string, faulthandler.enable() is called at startup: install a handler for SIGSEGV, SIGFPE, SIGABRT, SIGBUS and SIGILL signals to dump the Python traceback.
This is equivalent to the -X faulthandler option.
PYTHONEXECUTABLE If this environment variable is set, sys.argv[0] will be set to its value instead of the value got through the C runtime. Only works on Mac OS X.
PYTHONUSERBASE Defines the user base directory, which is used to compute the path of the user site-packages directory and Distutils installation paths for python setup.py install --user.
PYTHONPROFILEIMPORTTIME If this environment variable is set to a non-empty string, Python will show how long each import takes. This is exactly equivalent to setting -X importtime on the command line.
PYTHONBREAKPOINT If this environment variable is set to 0, it disables the default debugger. It can be set to the callable of your debugger of choice.
Debug-mode variables Setting these variables only has an effect in a debug build of Python, that is, if Python was configured with the --with-pydebug build option.
PYTHONTHREADDEBUG If this environment variable is set, Python will print threading debug info.
PYTHONDUMPREFS If this environment variable is set, Python will dump objects and reference counts still alive after shutting down the interpreter.
The Python Software Foundation: https://www.python.org/psf/
Main website:  https://www.python.org/ Documentation:  https://docs.python.org/ Developer resources:  https://devguide.python.org/ Downloads:  https://www.python.org/downloads/ Module repository:  https://pypi.org/ Newsgroups:  comp.lang.python, comp.lang.python.announce
Python is distributed under an Open Source license.  See the file "LICENSE" in the Python source distribution for information on terms & conditions for accessing and otherwise using Python and for a DISCLAIMER OF ALL WARRANTIES.
SUM(1)                            User Commands                           SUM(1)
sum - checksum and count the blocks in a file
sum [OPTION]... [FILE]...
Print or check BSD (16-bit) checksums.
-r     use BSD sum algorithm (the default), use 1K blocks
-s, --sysv use System V sum algorithm, use 512 bytes blocks
Written by Kayvan Aghaiepour and David MacKenzie.
Full documentation <https://www.gnu.org/software/coreutils/sum> or available locally via: info '(coreutils) sum invocation'
TESTSSL(1)                                                            TESTSSL(1)
testssl
testssl.sh -- check encryption of SSL/TLS servers
testssl.sh [OPTIONS] <URI>, testssl.sh [OPTIONS] --file <FILE>
testssl.sh [BANNER OPTIONS]
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.
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.
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.
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. bash 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.
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 ./bin/.
testssl.sh URI 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 -E which are (order of appearance):
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.
1) SSL/TLS protocol check
2) standard cipher categories to give you upfront an idea for the ciphers supported
3) checks (perfect) forward secrecy: ciphers and elliptical curves
4) server preferences (server order)
5) server defaults (certificate info, TLS extensions, session information)
6) HTTP header (if HTTP detected or being forced via --assume-http)
7) vulnerabilities
8) testing each of 370 preconfigured ciphers
9) client simulation
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. testssl.sh -t=smtp --wide --openssl=/usr/bin/openssl <URI> (short options with equal sign) is equivalent to testssl.sh --starttls smtp --wide --openssl /usr/bin/openssl <URI> (long option without equal sign). Some command line options can also be preset via ENV variables. WIDE=true OPENSSL=/usr/bin/openssl testssl.sh --starttls=smtp <URI> would be the equivalent to the aforementioned examples. Preference has the command line over any environment variables.
<URI> or --file <FILE> always needs to be the last parameter.
BANNER OPTIONS --help (or no arg) display command line help
-b, --banner 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.
-v, --version same as before
-V [pattern] , --local [pattern] 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.
INPUT PARAMETERS URI 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 https. 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 /etc/hosts entry for the hostname.
--file <fname> or the equivalent -iL <fname> are mass testing options. Per default it implicitly turns on --warnings batch. In its first incarnation the mass testing option reads command lines from fname. fname consists of command lines of testssl, one line per instance. Comments after # are ignored, EOF 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 testssl.sh --wide --log --file <fname> . Each single line in fname 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.
Alternatively fname can be in nmap´s grep(p)able output format (-oG). 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 -t smtp 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.
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.
A typical internal conversion to testssl.sh file format from nmap´s grep(p)able format could look like:
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
Please note that fname 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.
--mode <serial|parallel>. Mass testing to be done serial (default) or parallel (--parallel is shortcut for the latter, --serial 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 MASS_TESTING_MODE can be defined to be either equal serial or parallel.
--warnings <batch|off>. The warnings parameter determines how testssl.sh will deal with situations where user input normally will be necessary. There are two options. batch 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 (--file). off 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 WARNINGS.
--connect-timeout <seconds> 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 seconds for the handshake to complete before giving up. This option only works if your OS has a timeout binary installed. CONNECT_TIMEOUT is the corresponding environment variable.
--openssl-timeout <seconds> 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 seconds 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 timeout: It automatically calls the binary with the right parameters. OPENSSL_TIMEOUT is the equivalent environment variable.
--basicauth <user:pass> 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.
SPECIAL INVOCATIONS -t <protocol>, --starttls <protocol> does a default run against a STARTTLS enabled protocol. protocol must be one of ftp, smtp, pop3, imap, xmpp, telnet, ldap, irc, lmtp, nntp, postgres, mysql. 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, LDAP currently only works with --ssl-native. telnet and irc is WIP.
--xmpphost <jabber_domain> 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.
--mx <domain|host> tests all MX records (STARTTLS on port 25) from high to low priority, one after the other.
--ip <ip> tests either the supplied IPv4 or IPv6 address instead of resolving host(s) in <URI>. IPv6 addresses need to be supplied in square brackets. --ip=one means: just test the first A record DNS returns (useful for multiple IPs). If -6 and --ip=one was supplied an AAAA record will be picked if available. The --ip option might be also useful if you want to resolve the supplied hostname to a different IP, similar as if you would edit /etc/hosts or /c/Windows/System32/drivers/etc/hosts. --ip=proxy tries a DNS resolution via proxy.
--proxy <host>:<port> does ANY check via the specified proxy. --proxy=auto 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 DNS_VIA_PROXY=true. OCSP revocation checking (-S --phone-out) 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 IGN_OCSP_PROXY=true 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.
-6 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. -6 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 HAS_IPv6 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.
--ssl-native 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.
--openssl <path_to_openssl> 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 ($PATH). 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 OPENSSL=<path_to_openssl>).
TUNING OPTIONS --bugs does some workarounds for buggy servers like padding for old F5 devices. The option is passed as -bug to openssl when needed, see s_client(1), environment preset via BUGS="-bugs" (1x dash). For the socket part testssl.sh has always workarounds in place to cope with broken server implementations.
--assuming-http 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.
-n, --nodns <min|none> tells testssl.sh which DNS lookups should be performed. min 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. none performs no DNS lookups at all. For the latter you either have to supply the IP address as a target, to use --ip or have the IP address in /etc/hosts. 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. NODNS is the environment variable for this.
--sneaky For HTTP header checks testssl.sh uses normally the server friendly HTTP user agent TLS tester from ${URL}. 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 SNEAKY=true).
--ids-friendly 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.
--phone-out 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.
--add-ca <cafile> enables you to add your own CA(s) for trust chain checks. cafile 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.
SINGLE CHECK OPTIONS 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.
-e, --each-cipher 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 --show-each. Per default it lists the following parameters: hexcode, OpenSSL cipher suite name, key exchange, encryption bits, IANA/RFC cipher suite name. Please note the --mapping parameter changes what cipher suite names you will see here and at which position. Also please note that the bit length for the encryption is shown and not the security 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.
-E, --cipher-per-proto is similar to -e, --each-cipher. It checks each of the possible ciphers, here: per protocol. If you want to display each cipher tested you need to add --show-each. The output is sorted by security strength, it lists the encryption bits though.
-s, --std, --standard tests certain lists of cipher suites / cipher categories by strength. Those lists are (openssl ciphers $LIST, $LIST from below:)
•   NULL encryption ciphers: ´NULL:eNULL´
•   Anonymous NULL ciphers: ´aNULL:ADH´
•   Export ciphers (w/o the preceding ones): ´EXPORT:!ADH:!NULL´
•   LOW (64 Bit + DES ciphers, without EXPORT ciphers): ´LOW:DES:RC2:RC4:!ADH:!EXP:!NULL:!eNULL´
•   3DES + IDEA Ciphers: ´3DES:IDEA:!aNULL:!ADH´
•   Average grade Ciphers: ´HIGH:MEDIUM:AES:CAMELLIA:ARIA:!IDEA:!CHACHA20:!3DES:!RC2:!RC4:!AESCCM8:!AESCCM:!AESGCM:!ARIAGCM:!aNULL´
•   Strong grade Ciphers (AEAD): ´AESGCM:CHACHA20:CamelliaGCM:AESCCM´
-f, --pfs, --fs,--nsa 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, --protocols 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, --preference 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.
-S, --server_defaults displays information from the server hello(s):
•   Available TLS extensions,
•   TLS ticket + session ID information/capabilities,
•   session resumption capabilities,
•   Time skew relative to localhost (most server implementations return random values).
•   Several certificate information
•   signature algorithm,
•   key size,
•   key usage and extended key usage,
•   fingerprints and serial
•   Common Name (CN), Subject Alternative Name (SAN), Issuer,
•   Trust via hostname + chain of trust against supplied certificates
•   EV certificate detection
•   experimental "eTLS" detection
•   validity: start + end time, how many days to go (warning for certificate lifetime >=5 years)
•   revocation info (CRL, OCSP, OCSP stapling + must staple). When --phone-out supplied it checks against the certificate issuer whether the host certificate has been revoked (plain OCSP, CRL).
•   displaying DNS Certification Authority Authorization resource record
•   Certificate Transparency info (if provided by server).
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 ADDITIONAL_CA_FILES, see section FILES 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 gmt_unix_time, 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.
-x <pattern>, --single-cipher <pattern> tests matched pattern of ciphers against a server. Patterns are similar to -V pattern , --local pattern, see above about matching.
-h, --header, --headers if the service is HTTP (either by detection or by enforcing via --assume-http. It tests several HTTP headers like
•   HTTP Strict Transport Security (HSTS)
•   HTTP Public Key Pinning (HPKP)
•   Server banner
•   HTTP date+time
•   Server banner like Linux or other Unix vendor headers
•   Application banner (PHP, RoR, OWA, SharePoint, Wordpress, etc)
•   Reverse proxy headers
•   Web server modules
•   IPv4 address in header
•   Cookie (including Secure/HTTPOnly flags)
•   Decodes BIG IP F5 non-encrypted cookies
•   Security headers (X-Frame-Options, X-XSS-Protection, Expect-CT,... , CSP headers). Nonsense is not yet detected here.
-c, --client-simulation 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 --wide option. If you want the full nine yards of clients displayed use the environment variable ALL_CLIENTS.
-g, --grease 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.
VULNERABILITIES -U, --vulnerable, --vulnerabilities Just tests all (of the following) vulnerabilities. The environment variable VULN_THRESHLD determines after which value a separate headline for each vulnerability is being displayed. Default is 1 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.
-H, --heartbleed 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 HEARTBLEED_MAX_WAITSOCK. 8 is the default.
-I, --ccs, --ccs-injection 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 CCS_MAX_WAITSOCK.
-T, --ticketbleed Checks for Ticketbleed memory leakage in BigIP loadbalancers.
-BB, --robot Checks for vulnerability to ROBOT / (Return Of Bleichenbacher´s Oracle Threat) attack.
-R, --renegotiation Tests renegotiation vulnerabilities. Currently there´s a check for Secure Renegotiation and for Secure Client-Initiated Renegotiation. Please be aware that vulnerable servers to the latter can likely be DoSed very easily (HTTP). A check for Insecure Client-Initiated Renegotiation is not yet implemented.
-C, --compression, --crime Checks for CRIME (Compression Ratio Info-leak Made Easy) vulnerability in TLS. CRIME in SPDY is not yet being checked for.
-B, --breach Checks for BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) 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 `--assume-http. Please note that only the URL supplied (normally "/" ) is being tested.
-O, --poodle Tests for SSL POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability. It basically checks for the existence of CBC ciphers in SSLv3.
-Z, --tls-fallback 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.
-W, --sweet32 Checks for vulnerability to SWEET32 by testing 64 bit block ciphers (3DES, RC2 and IDEA).
-F, --freak Checks for FREAK vulnerability (Factoring RSA Export Keys) by testing for EXPORT RSA ciphers
-D, --drown Checks for DROWN vulnerability (Decrypting RSA with Obsolete and Weakened eNcryption) 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.
-J, --logjam 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.
-A, --beast Checks BEAST vulnerabilities in SSL 3 and TLS 1.0 by testing the usage of CBC ciphers.
-L, --lucky13 Checks for LUCKY13 vulnerability. It checks for the presence of CBC ciphers in TLS versions 1.0 - 1.2.
-4, --rc4, --appelbaum Checks which RC4 stream ciphers are being offered.
OUTPUT OPTIONS -q, --quiet 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.
--wide 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 WIDE can be used instead.
--mapping <openssl|iana|no-openssl|no-iana>
•   openssl: use the OpenSSL cipher suite name as the primary name cipher suite name form (default),
•   iana: use the IANA cipher suite name as the primary name cipher suite name form.
•   no-openssl: don´t display the OpenSSL cipher suite name, display IANA names only.
•   no-iana: don´t display the IANA cipher suite name, display OpenSSL names only.
Please note that in testssl.sh 3,0 you can still use rfc instead of iana and no-rfc instead of no-iana but it´ll disappear after 3.0.
--show-each This is an option for all wide modes only: it displays all ciphers tested -- not only succeeded ones. SHOW_EACH_C is your friend if you prefer to set this via the shell environment.
--color <0|1|2|3> determines the use of colors on the screen and in the log file: 2 is the default and makes use of ANSI and termcap escape codes on your terminal. 1 just uses non-colored mark-up like bold, italics, underline, reverse. 0 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. 3 will color ciphers and EC according to an internal (not yet perfect) rating. Setting the environment variable COLOR to the value achieves the same result. Please not that OpenBSD and early FreeBSD do not support italics.
--colorblind 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. COLORBLIND is the according variable if you want to set this in the environment.
--debug <0-6> This gives you additional output on the screen (2-6), only useful for debugging. DEBUG is the according environment variable which you can use. There are six levels (0 is the default, thus it has no effect):
1.  screen output normal but leaves useful debug output in /tmp/testssl.XXXXXX/ . The info about the exact directory is included in the screen output in the end of the run.
2.  lists more what´s going on, status (high level) and connection errors, a few general debug output
3.  even slightly more info: hexdumps + other info
4.  display bytes sent via sockets
5.  display bytes received via sockets
6.  whole 9 yards
FILE OUTPUT OPTIONS --log, --logging Logs stdout also to ${NODE}-p${port}${YYYYMMDD-HHMM}.log 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 --color 0 too. cat and -- if properly configured less -- 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.
--logfile <logfile> or -oL <logfile> 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 logfile is a directory the output will put into logfile/${NODE}-p${port}${YYYYMMDD-HHMM}.log. If logfile 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.
--json Logs additionally to JSON file ${NODE}-p${port}${YYYYMMDD-HHMM}.json in the current working directory of the shell. The resulting JSON file is opposed to --json-pretty 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.
--jsonfile <jsonfile> or -oj <jsonfile> 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 jsonfile is a directory the output will put into logfile/${NODE}-p${port}${YYYYMMDD-HHMM}.json. Ifjsonfile` is a file it will use that file name, an absolute path is also permitted here.
--json-pretty Logs additionally to JSON file ${NODE}-p${port}${YYYYMMDD-HHMM}.json in the current working directory of the shell. The resulting JSON file is opposed to--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.
--jsonfile-pretty <jsonfile> or -oJ <jsonfile> Similar to the aforementioned --jsonfile or --logfile it logs the output in pretty JSON format (see --json-pretty) into a file or a directory. For further explanation see --jsonfile or --logfile.
--csv Logs additionally to a CSV file ${NODE}-p${port}${YYYYMMDD-HHMM}.csv 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).
--csvfile <csvfile> or -oC <csvfile> Similar to the aforementioned --jsonfile or --logfile it logs the output in CSV format (see --cvs) additionally into a file or a directory. For further explanation see --jsonfile or --logfile.
--html Logs additionally to an HTML file ${NODE}-p${port}${YYYYMMDD-HHMM}.html 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 testssl.sh [options] <URI> | aha >output.html. This is not necessary anymore.
--htmlfile <htmlfile> or -oH <htmlfile> Similar to the aforementioned --jsonfile or --logfile it logs the output in HTML format (see --html) additionally into a file or a directory. For further explanation see --jsonfile or --logfile.