Fix spelling

doc/testssl.1

@@ -125,7 +125,7 @@ Please note that \fBfname\fR has to be in Unix format\. DOS carriage returns won
 \fB\-\-mode <serial|parallel>\fR\. Mass testing to be done serial (default) or parallel (\fB\-\-parallel\fR is shortcut for the latter, \fB\-\-serial\fR 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 \fBMASS_TESTING_MODE\fR can be defined to be either equal \fBserial\fR or \fBparallel\fR\.
 .
 .P
-\fB\-\-warnings <batch|off>\fR\. The warnings parameter determines how testssl\.sh will deal with situations where user input normally will be necessary\. There are two options\. \fBbatch\fR doesn\'t wait for a confirming keypress when a client\- or server\-side probem is encountered\. As of 3\.0 it just then terminates the particular scan\. This is automatically chosen for mass testing (\fB\-\-file\fR)\. \fBoff\fR 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 \fBWARNINGS\fR\.
+\fB\-\-warnings <batch|off>\fR\. The warnings parameter determines how testssl\.sh will deal with situations where user input normally will be necessary\. There are two options\. \fBbatch\fR 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 (\fB\-\-file\fR)\. \fBoff\fR 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 \fBWARNINGS\fR\.
 .
 .P
 \fB\-\-connect\-timeout <seconds>\fR 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 \fBseconds\fR 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\.
@@ -342,7 +342,7 @@ Security headers (X\-Frame\-Options, X\-XSS\-Protection, Expect\-CT,\.\.\. , CSP
 \fB\-g, \-\-grease\fR checks several server implementation bugs like tolerance to size limitations and GREASE, see RFC 8701\. This check doesn\'t run per default\.
 .
 .SS "VULNERABILITIES"
-\fB\-U, \-\-vulnerable, \-\-vulnerabilities\fR Just tests all (of the following) vulnerabilities\. The environment variable \fBVULN_THRESHLD\fR determines after which value a separate headline for each vulnerability is being displayed\. Default is \fB1\fR 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\.
+\fB\-U, \-\-vulnerable, \-\-vulnerabilities\fR Just tests all (of the following) vulnerabilities\. The environment variable \fBVULN_THRESHLD\fR determines after which value a separate headline for each vulnerability is being displayed\. Default is \fB1\fR which means if you check for two vulnerabilities, only the general headline for vulnerabilities section is displayed \-\- in addition to the vulnerability and the result\. Otherwise each vulnerability or vulnerability section gets its own headline in addition to the output of the name of the vulnerability and test result\. A vulnerability section is comprised of more than one check, e\.g\. the renegotiation vulnerability check has two checks, so has Logjam\.
 .
 .P
 \fB\-H, \-\-heartbleed\fR 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 \fBHEARTBLEED_MAX_WAITSOCK\fR\. 8 is the default\.

doc/testssl.1.html

@@ -178,7 +178,7 @@ host.example.com:631
 
 <p><code>--mode &lt;serial|parallel></code>. Mass testing to be done serial (default) or parallel (<code>--parallel</code> is shortcut for the latter, <code>--serial</code> is the opposite option). Per default mass testing is being run in serial mode, i.e. one line after the other is processed and invoked. The variable <code>MASS_TESTING_MODE</code> can be defined to be either equal <code>serial</code> or <code>parallel</code>.</p>
 
-<p><code>--warnings &lt;batch|off></code>.  The warnings parameter determines how testssl.sh will deal with situations where user input normally will be necessary. There are two options. <code>batch</code> doesn't wait for a confirming keypress when a client- or server-side probem is encountered. As of 3.0 it just then terminates the particular scan.  This is automatically chosen for mass testing (<code>--file</code>). <code>off</code> just skips the warning, the confirmation but continues the scan, independent whether it makes sense or not. Please note that there are conflicts where testssl.sh will still ask for confirmation which are the ones which otherwise would have a drastic impact on the results. Almost any other decision will be made in the future as a best guess by testssl.sh.
+<p><code>--warnings &lt;batch|off></code>.  The warnings parameter determines how testssl.sh will deal with situations where user input normally will be necessary. There are two options. <code>batch</code> doesn't wait for a confirming keypress when a client- or server-side problem is encountered. As of 3.0 it just then terminates the particular scan.  This is automatically chosen for mass testing (<code>--file</code>). <code>off</code> just skips the warning, the confirmation but continues the scan, independent whether it makes sense or not. Please note that there are conflicts where testssl.sh will still ask for confirmation which are the ones which otherwise would have a drastic impact on the results. Almost any other decision will be made in the future as a best guess by testssl.sh.
 The same can be achieved by setting the environment variable <code>WARNINGS</code>.</p>
 
 <p><code>--connect-timeout &lt;seconds></code>  This is useful for socket TCP connections to a node. If the node does not complete a TCP handshake (e.g. because it is down or behind a firewall or there's an IDS or a tarpit) testssl.sh may usually hang for around 2 minutes or even much more. This parameter instructs testssl.sh to wait at most <code>seconds</code> for the handshake to complete before giving up. This option only works if your OS has a timeout binary installed. CONNECT_TIMEOUT is the corresponding environment variable.</p>
@@ -312,7 +312,7 @@ Also for multiple server certificates are being checked for as well as for the c
 
 <h3 id="VULNERABILITIES">VULNERABILITIES</h3>
 
-<p><code>-U, --vulnerable, --vulnerabilities</code> Just tests all (of the following) vulnerabilities. The environment variable <code>VULN_THRESHLD</code> determines after which value a separate headline for each vulnerability is being displayed. Default is <code>1</code> which means if you check for two vulnerabilities, only the general headline for vulnerabilities section is displayed -- in addition to the vulnerability and the result. Otherwise each vulnerability or vulnerability section gets its own headline in addition to the output of the name of the 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>-U, --vulnerable, --vulnerabilities</code> Just tests all (of the following) vulnerabilities. The environment variable <code>VULN_THRESHLD</code> determines after which value a separate headline for each vulnerability is being displayed. Default is <code>1</code> which means if you check for two vulnerabilities, only the general headline for vulnerabilities section is displayed -- in addition to the vulnerability and the result. Otherwise each vulnerability or vulnerability section gets its own headline in addition to the output of the name of the vulnerability and test result. A vulnerability section is comprised of more than one check, e.g. the renegotiation vulnerability check has two checks, so has Logjam.</p>
 
 <p><code>-H, --heartbleed</code>              Checks for Heartbleed, a memory leakage in openssl. Unless the server side doesn't support the heartbeat extension it is likely that this check runs into a timeout. The seconds to wait for a reply can be adjusted with <code>HEARTBLEED_MAX_WAITSOCK</code>. 8 is the default.</p>
 

doc/testssl.1.md

@@ -101,7 +101,7 @@ Please note that `fname` has to be in Unix format. DOS carriage returns won't be
 
 `--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 probem 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.
+`--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.
@@ -226,7 +226,7 @@ Also for multiple server certificates are being checked for as well as for the c
 
 ### 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 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.
+`-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.