mirror of
https://github.com/drwetter/testssl.sh.git
synced 2024-11-25 20:41:36 +01:00
draft status reached
few things still need to be done, see comments. Also proofreading (grammar and content)
Dirk
parent
40b18818aa
commit
81db9b6326
221
Man-page.md
221
Man-page.md
@ -1,8 +1,8 @@
|
||||
|
||||
### NAME
|
||||
## NAME
|
||||
testssl.sh -- check encryption of SSL/TLS servers
|
||||
|
||||
### SYNOPSIS
|
||||
## SYNOPSIS
|
||||
|
||||
|
||||
`testssl.sh [OPTIONS] <URI>`, `testssl.sh [OPTIONS] --file <FILE>`
|
||||
@ -11,19 +11,20 @@
|
||||
|
||||
`testssl.sh [BANNER OPTIONS]`
|
||||
|
||||
### DESCRIPTION
|
||||
## DESCRIPTION
|
||||
|
||||
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 rate 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.
|
||||
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.
|
||||
|
||||
Except DNS lookups it doesn't use any third parties for checks, it's only you who sees the result and you also can use it internally on your LAN.
|
||||
|
||||
It is out of the box pretty much portable: testssl.sh runs under any Unix-like stack (Linux, *BSD, MacOS X, WSL=bash on Windows, Cygwin and MSYS2). `bash` (also version 3) is a prerequisite as well as standard utilities like awk, sed, tr and head. This can be of BSD, System 5 or GNU flavor whereas grep from System V is not yet supported. Windows is known to be slow.
|
||||
It is out of the box pretty much portable: testssl.sh runs under any Unix-like stack (Linux, *BSD, MacOS X, WSL=bash on Windows, Cygwin and MSYS2). `bash` (also version 3 is still supported) is a prerequisite as well as standard utilities like awk, sed, tr and head. This can be of BSD, System 5 or GNU flavor whereas grep from System V is not yet supported.
|
||||
|
||||
### GENERAL
|
||||
|
||||
`testssl.sh URI` is 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 under CHECKS except `-E`. Following checks are being done (order of appearance) by `testssl.sh <OPTIONS> URI`
|
||||
## GENERAL
|
||||
|
||||
`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.
|
||||
|
||||
@ -45,9 +46,9 @@ It is out of the box pretty much portable: testssl.sh runs under any Unix-like s
|
||||
|
||||
9) client simulation
|
||||
|
||||
### OPTIONS
|
||||
## OPTIONS AND PARAMETERS
|
||||
|
||||
Options are either short or long options. All options requiring a value can be called with or without '=' e.g. `testssl.sh -t=smtp --wide --openssl=/usr/bin/openssl <URI>` is equivalent to `testssl.sh --starttls smtp --wide --openssl /usr/bin/openssl <URI>`. Some 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 enviroment variables.
|
||||
Options are either short or long options. All options requiring a value can be called with or without an equal sign '=' e.g. `testssl.sh -t=smtp --wide --openssl=/usr/bin/openssl <URI>` is equivalent to `testssl.sh --starttls smtp --wide --openssl /usr/bin/openssl <URI>`. 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 enviroment variables.
|
||||
|
||||
`<URI>` or `--file <FILE>` always needs to be the last parameter.
|
||||
|
||||
@ -83,15 +84,15 @@ 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.
|
||||
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`.
|
||||
`--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`.
|
||||
|
||||
|
||||
##### SPECIAL INVOCATIONS:
|
||||
### SPECIAL INVOCATIONS
|
||||
|
||||
`-t <protocol>, --starttls <protocol>` does a default run against a STARTTLS enabled `<protocol>`. `<protocol>` is one of `ftp`, `smtp`, `pop3`, `imap`, `xmpp`, `telnet`, `ldap`, `postgres`. For the latter three two you need e.g. the supplied openssl.
|
||||
`-t <protocol>, --starttls <protocol>` does a default run against a STARTTLS enabled `<protocol>`. `<protocol>` is one of `ftp`, `smtp`, `pop3`, `imap`, `xmpp`, `telnet`, `ldap`, `postgres`, `mysql`. For the latter four you need e.g. the supplied openssl.
|
||||
|
||||
`--xmpphost <jabber_domain>` is an additional option for STARTTLS enabled XMPP: It expects as a parameter the jabber domain. This is only needed if the domain is different from the URI supplied.
|
||||
|
||||
@ -100,7 +101,7 @@ Please note that `<fname>` has to be in Unix format. DOS carriage returns won't
|
||||
`--ip <ip>` tests either the supplied IPv4 or IPv6 address instead of resolving host(s) in `<URI>`. IPv6 addresses needs to be in square brackets.
|
||||
`--ip=one` means: just test the first DNS returns (useful for multiple IPs). It's 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 the whole check via the specified HTTP proxy. `--proxy=auto` inherits the proxy setting from the environment. Proxying via IPv6 addresses is not possible. The hostname supplied will only be resolved to the first A record. Authentication to the proxy is not supported.
|
||||
`--proxy <host>:<port>` does the whole check via the specified HTTP proxy. `--proxy=auto` inherits the proxy setting from the environment. Proxying via IPv6 addresses is not possible. The hostname supplied will only be resolved to the first A record. Authentication to the proxy is not supported. In addition if you want lookups via proxy you can specify `DNS_VIA_PROXY=true`.
|
||||
|
||||
`-6` does (also) IPv6 checks. This works only with both a supporting openssl binary like the one supplied and IPv6 connectivity. testssl.sh does no connectivity checks for IPv6, it also cannot determine reliably whether the OpenSSL binary you are using has IPv6 support. `HAS_IPv6` is the respective enviroment variable.
|
||||
|
||||
@ -114,16 +115,16 @@ Please note that `<fname>` has to be in Unix format. DOS carriage returns won't
|
||||
`--assuming-http` testssl.sh does upfront a protocol detection on the application layer. In cases where for some reasons the usage of HTTP cannot be automatically detected you may want to use this option. It helps you to tell testssl.sh not to skip HTTP specific tests and to run the client simulation with browsers. 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, --no-dns` instructs testssl.sh to not do any DNS lookups. It's useful if you either can't or are not willing to perform DNS lookups. The latter applies e.g. to some pentests, the former could e.g. help you to avoid timeouts by DNS lookups.
|
||||
* `-n, --no-dns` instructs testssl.sh to not do any DNS lookups. This is useful if you either can't or are not willing to perform DNS lookups. The latter applies e.g. to some pentests, the former could e.g. help you to avoid timeouts by DNS lookups. `NODNS=true` has the same effect.
|
||||
|
||||
* `--sneaky` as a friendly feature for the server side testssl.sh uses a user agent `TLS tester from ${URL}` (HTTP). 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`).
|
||||
|
||||
|
||||
### SINGLE CHECK OPTIONS
|
||||
|
||||
Any single option supplied 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.
|
||||
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 local 359 cipher (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`. The default is here to list the following parameter: `hexcode`,`OpenSSL cipher suite name`,`key exchange`, `encryption bits`, `RFC cipher suite name (RFC)`. 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. 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, --each-cipher` checks each of the local 359 cipher (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`. The default is here to list the following parameter: `hexcode`, `OpenSSL cipher suite name`,i `key exchange`, `encryption bits`, `RFC cipher suite name (RFC)`. 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. 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` checks each of the possible ciphers per protocol. If you want to display each cipher tested you need to add `--show-each`
|
||||
@ -170,11 +171,11 @@ If the server provides no matching record in Subject Alternative Name (SAN) but
|
||||
|
||||
`-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 (unit: seconds)
|
||||
|
||||
`-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 enviroment variable `CCS_MAX_WAITSOCK`
|
||||
`-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 enviroment variable `CCS_MAX_WAITSOCK`.
|
||||
|
||||
`-T, --ticketbleed` Checks for Ticketbleed memory leakage in BigIP loadbalancers
|
||||
`-T, --ticketbleed` Checks for Ticketbleed memory leakage in BigIP loadbalancers.
|
||||
|
||||
`-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
|
||||
`-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.
|
||||
|
||||
@ -184,9 +185,9 @@ If the server provides no matching record in Subject Alternative Name (SAN) but
|
||||
|
||||
`-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 vulnerabilty to SWEET32 by testing 64 bit block ciphers (3DES, RC2 and IDEA).
|
||||
`-W, --sweet32` Checks for vulnerabilty to SWEET32 by testing 64 bit block ciphers (3DES, RC2 and IDEA).
|
||||
|
||||
`-A, --beast` Checks BEAST vulnerabilities in SSLv3 and TLSv1.0 by testing the usage of CBC ciphers.
|
||||
`-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 all TLS versions.
|
||||
|
||||
@ -194,7 +195,7 @@ If the server provides no matching record in Subject Alternative Name (SAN) but
|
||||
|
||||
`-J, --logjam` Checks for LOGJAM vulnerability by checking for DH EXPORT ciphrs. It also checks for "common primes" which are preconfigured DH keys. DH keys =< 1024 Bit will be penalized
|
||||
|
||||
`-D, --drown` Checks for DROWN vulnerability by checking whether the SSLv2 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.
|
||||
`-D, --drown` Checks for DROWN vulnerability 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.
|
||||
|
||||
`-f, --pfs, --fs,--nsa ` Checks robust (perfect) forward secrecy settings. "Robust" means -- as the headline says -- that ciphers having intrinsic severe weaknesses like "Null Authentication/Encryption, 3DES, 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.
|
||||
|
||||
@ -203,17 +204,14 @@ If the server provides no matching record in Subject Alternative Name (SAN) but
|
||||
|
||||
### OUTPUT OPTIONS
|
||||
|
||||
|
||||
`--warnings <batch|off>` The warnings parameter determines how testssl.sh will deal with situations where user input will normally be necessary. There are a couple of options here. `batch` doesn\'t wait for a confirming keypress. This is automatically being chosen for mass testing (`--file`). `-false` just skips the warning AND the confirimation. Please note that there are conflicts where testssl.sh will still asking for confirmation. Those are ones which would have a drastic impact on the results.
|
||||
`--warnings <batch|off>` The warnings parameter determines how testssl.sh will deal with situations where user input will normally be necessary. There are a couple of options here. `batch` doesn't wait for a confirming keypress. This is automatically being chosen for mass testing (`--file`). `-false` just skips the warning AND the confirmation. Please note that there are conflicts where testssl.sh will still ask for confirmation. Those are ones which would have a drastic impact on the results.
|
||||
The same can be achived by setting the environment variable `WARNINGS`.
|
||||
|
||||
`--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 to wait before 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 <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.
|
||||
|
||||
`-q, --quiet` Normally testssl.sh displays on stdout a banner with several version banner, usage rights and a warning. By using this option it'll be supressed. By chosing this option you acknowledge usage terms and the warning normally appearing in the banner.
|
||||
`-q, --quiet` Normally testssl.sh displays a banner on stdout with several version information, usage rights and a warning. This option suppresses it. Pleas not that by chosing 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.
|
||||
`--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|rfc|no-openssl|no-rfc>`
|
||||
@ -221,99 +219,114 @@ The environment variable `WIDE` can be used instead.
|
||||
* `openssl`: use the OpenSSL cipher suite name as the primary name cipher suite name form (default),
|
||||
* `rfc`: use the RFC cipher suite name as the primary name cipher suite name form.
|
||||
* `no-openssl`: don't display the OpenSSL cipher suite name, display RFC names only.
|
||||
* `no-rfc`: don't display the RFC cipher suite name, display OpenSSL names only
|
||||
* `no-rfc`: don't display the RFC cipher suite name, display OpenSSL names only.
|
||||
|
||||
|
||||
`--show-each` This is an option for all wide modes -- i.e. per switch or the each cipher test: 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.
|
||||
`--show-each` This is an option for all wide modes -- i.e. per switch or the each cipher test: 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>` It determines the use of colors on the screen: `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.
|
||||
|
||||
Setting the environment varable `COLOR` achives the same result.
|
||||
`--color <0|1|2>` It determines the use of colors on the screen: `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. Setting the environment varable `COLOR` achives the same result.
|
||||
|
||||
|
||||
`--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 distuingish those findings better
|
||||
`--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 distuingish those findings better. `COLORBLIND` is the according variable if you want to set this in the environment.
|
||||
|
||||
`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 enviroment variable which you can use. There are six levels (0 is the default, thus it has no effect):
|
||||
|
||||
`--debug <0-6>` This gives you additional output on the screen (2-6), only useful for debugging:
|
||||
|
||||
0. none (default)
|
||||
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.
|
||||
2. list more what\'s going on, e.g. lists some errors of connections and general debug statements
|
||||
2. list more what's going on, e.g. lists some errors of connections and general debug statements
|
||||
3. even slightly more info: hexdumps + other info
|
||||
4. display bytes sent via sockets
|
||||
5. display bytes received via sockets
|
||||
6. whole 9 yards
|
||||
|
||||
`DEBUG` is the according enviroment variable.
|
||||
|
||||
|
||||
### FILE OUTPUT OPTIONS
|
||||
|
||||
A few file output options can also be preset via environment variables.
|
||||
`--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. `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 runing testssl.sh.
|
||||
|
||||
--log, --logging logs stdout to <NODE-YYYYMMDD-HHMM.log> in current working directory
|
||||
--logfile <logfile> logs stdout to <file/NODE-YYYYMMDD-HHMM.log> if file is a dir or to specified log file
|
||||
--json additional output of findings to JSON file <NODE-YYYYMMDD-HHMM.json> in cwd
|
||||
--jsonfile <jsonfile> additional output to JSON and output JSON to the specified file
|
||||
--json-pretty additional JSON structured output of findings to a file <NODE>-p<port#><YYYYMMDD-HHMM>.json in cwd
|
||||
--jsonfile-pretty <jsonfile> additional JSON structured output to the specified file or directory, similar to --logfile
|
||||
--csv additional output of findings to CSV file <NODE-YYYYMMDD-HHMM.csv> in cwd
|
||||
--csvfile <csvfile> set output to CSV and output CSV to the specified file
|
||||
--html additional output as HTML to file <NODE>-p<port#><YYYYMMDD-HHMM>.html
|
||||
--htmlfile <htmlfile> additional output as HTML to the specifed file or directory, similar to --logfile
|
||||
<!--Need HTML output? Just pipe through "aha" (Ansi HTML Adapter: github.com/theZiz/aha) like
|
||||
`testssl.sh <options> <URI> | aha >output.html` -->
|
||||
--hints
|
||||
--severity <severity> severities with lower level will be filtered for CSV+JSON, possible values <LOW|MEDIUM|HIGH|CRITICAL>
|
||||
--append if <csvfile> or <jsonfile> exists rather append then overwrite
|
||||
`--logfile <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 run
|
||||
ing testssl.sh.
|
||||
|
||||
`--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>` 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`. If `<jsonfile>`is a file it will use that file name, an absolute path is also permitted here. JSONFILE is the variable you need to set if you prefer to work environment variables instead.
|
||||
|
||||
`--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 (with the epoch of the start time) and then for every test section of testssl.sh it contains a seperate 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>` Similar to the aforementioned `--jsonfile` or `--logfile` it logs the output in pretty JSON format (see `--json-pretty`) additionally into a file or a directory. For further explanation see `--jsonfile` or ``--logfile`. `JSONFILE` is the variable you need to set if you prefer to work environment with variables instead.
|
||||
|
||||
`--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 too).
|
||||
|
||||
`--csvfile <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`. `CSVFILE` is the variable you need to set if you prefer to work environment with variables instead.
|
||||
|
||||
--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 konsole. 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 neccessary anymore.
|
||||
|
||||
`--htmlfile <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`. `HTMLFILE` is the variable you need to set if you prefer to work with environment variables instead.
|
||||
|
||||
`--hints` Thios 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.
|
||||
|
||||
`--severity <severity>` For JSON and CSV output this will only add findings to the output file if a severity is equal or higher than the `<severity>` value specified. Allowed are `<LOW|MEDIUM|HIGH|CRITICAL>`
|
||||
|
||||
`--append` If an output file exists it will append to this file, without a header. The environment variable APPEND does the same. If the file exists and you don't use `--append` testssl.sh will exit with an error. Be careful using this switch/variable. A complementary option which overwrites an existing file doesn't exist per design.
|
||||
|
||||
|
||||
A few file output options can also be preset via environment variables.
|
||||
|
||||
### COLOR RATINGS
|
||||
|
||||
Testssl.sh makes use of standard terminal colors (currently: 8). The color scheme is as follows:
|
||||
Testssl.sh makes use of (the eight) standard terminal colors. The color scheme is as follows:
|
||||
|
||||
* light red: a critical finding
|
||||
* red: a high finding
|
||||
* brown: a medium finding
|
||||
* yellow: a low finding
|
||||
* 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
|
||||
* light green (light blue if COLORBLIND) : something which is either in general a very good thing or a negative result of a check which otherwise results in a critical finding
|
||||
* 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
|
||||
* no color at places where also a finding can be expected: a finding on an info level
|
||||
* cyan: currently used for `--show-each` or an additional hint
|
||||
* magenta: signals a warning condition, e.g. either a local lack of capabilities on the client side or another problem
|
||||
* 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
|
||||
|
||||
What is labeled as "light" above appears as such on the screen but is in technically "bold". Markup (without any color) is used in the following manner:
|
||||
What is labeled as "light" above appears as such on the screen but is technically speaking "bold". Markup (without any color) is used in the following manner:
|
||||
|
||||
* bold: for the name of the test
|
||||
* underline + bold: for the headline of each test section
|
||||
* underline: for a sub-headline
|
||||
* italics: for strings just reflecting a value
|
||||
* italics: for strings just reflecting a value read from the server
|
||||
|
||||
|
||||
### TUNING via ENV variables and more options
|
||||
|
||||
Except the environment variables which replace command line options here a some VARIABLES which cannot be set otherwise. Variables used for tuning are preset with reasonable values. There should be no reason to change them unless you use testssl.sh under special conditions.
|
||||
Except the environment variables mentioned above which replace command line options here a some which cannot be set otherwise. Variables used for tuning are preset with reasonable values. There should be no reason to change them unless you use testssl.sh under special conditions.
|
||||
|
||||
* DEBUGTIME
|
||||
* DEBUG_ALLINONE
|
||||
* FAST_SOCKET
|
||||
* SHOW_SIGALGO
|
||||
* FAST
|
||||
* EXPERIMENTAL
|
||||
* UNBRACKTD_IPV6 some versions of OpenSSL (like from Gentoo) don\'t support [bracketed] IPv6 addresses
|
||||
[comment]: # * DEBUGTIME
|
||||
[comment]: # * DEBUG_ALLINONE
|
||||
[comment]: # * FAST_SOCKET
|
||||
[comment]: # * SHOW_SIGALGO
|
||||
[comment]: # * FAST
|
||||
[comment]: # * EXPERIMENTAL
|
||||
* UNBRACKTD_IPV6: needs to be set to true for some versions of OpenSSL (like from Gentoo) which don't support [bracketed] IPv6 addresses
|
||||
* HEADER_MAXSLEEP: To wait how long before killing the process to retrieve a service banner / HTTP header
|
||||
* readonly MAX_WAITSOCK=10 # waiting at max 10 seconds for socket reply
|
||||
* readonly CCS_MAX_WAITSOCK=5 # for the two CCS payload (each)
|
||||
* readonly HEARTBLEED_MAX_WAITSOCK=8 # for the heartbleed payload
|
||||
* 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.
|
||||
* 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.
|
||||
* 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.
|
||||
* 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.
|
||||
|
||||
[comment]: # STARTTLS_SLEEP
|
||||
[comment]: # FAST_STARTTLS
|
||||
[comment]: # USLEEP_SND
|
||||
[comment]: # USLEEP_REC
|
||||
[comment]: # HSTS_MIN
|
||||
[comment]: # HPKP_MIN
|
||||
[comment]: # DAYS2WARN1
|
||||
[comment]: # DAYS2WARN2
|
||||
[comment]: # TESTSSL_INSTALL_DIR
|
||||
[comment]: # CA_BUNDLES_PATH
|
||||
[comment]: # CAPATH
|
||||
|
||||
|
||||
|
||||
|
||||
### EXAMPLES
|
||||
## EXAMPLES
|
||||
|
||||
testssl.sh testssl.sh
|
||||
|
||||
@ -325,7 +338,7 @@ does the same default run as above with the subtle difference that testssl.net h
|
||||
|
||||
testssl.sh --ip=one --wide https://testssl.net:443
|
||||
|
||||
does the same checks as above, only (randomly) one IP address is picked. Displayed is everything where possible in wide format.
|
||||
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.
|
||||
|
||||
testssl.sh -t smtp smtp.gmail.com:25
|
||||
|
||||
@ -335,17 +348,8 @@ implicilty does a STARTTLS handshake on the plain text port, then check the IPs
|
||||
|
||||
does the same on the plain text IMAP port. Please note that for plain TLS-encrypted ports you must not specify the protocol option: `testssl.sh smtp.gmail.com:465` tests the encryption on the SMTPS port, `testssl.sh imap.gmx.net:993` on the IMAPS port.
|
||||
|
||||
### Exit status
|
||||
|
||||
* 0 testssl.sh finished successfully
|
||||
* 245 no bash used
|
||||
* 249 temp file creation problem
|
||||
* 251 feature not yet supported
|
||||
* 252 no DNS resolver found or not executable / proxy couldn't be determined from given values / -xmpphost supplied but OPENSSL too old
|
||||
* 253 no SSL/TLS enabled server / OPENSSL too old / couldn\'t connect to proxy / couldn't connect via STARTTLS
|
||||
* 254 no OPENSSL found or not exexutable / no IPv4 address could be determined / illegal STARTTLS protocol supplied / supplied file name not readable
|
||||
|
||||
### RFCs and other standards
|
||||
## RFCs and other standards
|
||||
|
||||
* RFC 2246: The TLS Protocol Version 1.0
|
||||
* RFC 2818: HTTP Over TLS
|
||||
@ -378,28 +382,47 @@ does the same on the plain text IMAP port. Please note that for plain TLS-encryp
|
||||
* TLSWG Draft: The Transport Layer Security (TLS) Protocol Version 1.3
|
||||
|
||||
|
||||
### FILES
|
||||
## EXIT STATUS
|
||||
|
||||
**etc/\*pem** certificate stores from Apple, Linux, Mozilla Firefox, Windows
|
||||
* 0 testssl.sh finished successfully
|
||||
* 245 no bash used
|
||||
* 249 temp file creation problem
|
||||
* 251 feature not yet supported
|
||||
* 252 no DNS resolver found or not executable / proxy couldn't be determined from given values / -xmpphost supplied but OPENSSL too old
|
||||
* 253 no SSL/TLS enabled server / OPENSSL too old / couldn't connect to proxy / couldn't connect via STARTTLS
|
||||
* 254 no OPENSSL found or not executable / no IPv4 address could be determined / illegal STARTTLS protocol supplied / supplied file name not readable
|
||||
|
||||
**etc/mapping-rfc.txt** provides a mandatory file with mapping from OpenSSL cipher suites names to the ones from IANA / used in the RFCs
|
||||
|
||||
**etc/tls_data.txt** provides a mandatory file for ciphers (bash sockets) and key material
|
||||
### AUTHORS
|
||||
## FILES
|
||||
|
||||
**etc/\*pem** Here are the certificate stores from Apple, Linux, Mozilla Firefox, Windows.
|
||||
|
||||
**etc/mapping-rfc.txt** Provides a mandatory file with mapping from OpenSSL cipher suites names to the ones from IANA / used in the RFCs.
|
||||
|
||||
**etc/tls_data.txt** Provides a mandatory file for ciphers (bash sockets) and key material.
|
||||
|
||||
|
||||
## AUTHORS
|
||||
|
||||
Developed by Dirk Wetter and others, see https://github.com/drwetter/testssl.sh/blob/master/CREDITS.md
|
||||
|
||||
### COPYRIGHT
|
||||
|
||||
Copyright © 2014 Dirk Wetter. License GPLv2: Free Software Foundation, Inc.
|
||||
## COPYRIGHT
|
||||
|
||||
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!
|
||||
|
||||
## LIMITATION
|
||||
|
||||
### BUGS
|
||||
The Windows implementation is known to be slow.
|
||||
|
||||
|
||||
## BUGS
|
||||
|
||||
Known ones and interface for filing new ones: https://testssl.sh/bugs/ .
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
ciphers(1), openssl(1), s_client(1)
|
||||
## SEE ALSO
|
||||
|
||||
`ciphers`(1), `openssl`(1), `s_client`(1), `x509`(1), `verify`(1), `ocsp`(1), `crl`(1), `bash`(1) and the websites __https://testssl.sh/__ and __https://github.com/drwetter/testssl.sh/__ .
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user