Therefore a new global function was declared checking whether any of
the known locales work on the client without seeting them.
C / POSIX should work as well for LC_COLLATE.
This fixes#2100 for 3.0 .
This PR addresses a bug where a user encountered the question "The results
might look ok but they could be nonsense. Really proceed".
That happened under Darwin and probably some LibreSSL versions when
checking some hosts. sclient_auth() returned 1 indicating no SSL/TLS
handshake could be established.
This PR modifies sclient_auth() so that in those cases 0 is returned by
skipping the check for the session ID. As NO_SSL_SESSIONID needs to
be set when there's no session ID. This is done separately.
This fixes#2052 for 3.0
See #2032 / #2067, kudos @Wahnes. This is a backport for 3.0
Currently, when "HTTP clock skew" is calculated, this is taken to be the
difference between the timestamp of the moment the HTTPS request was sent and
the date given in the HTTP Date header. This does not yield valid results in
case a HTTP cache is used, either on the client side or on the server side.
According to the HTTP specs, the Date field will contain the timestamp the
response was created, which may not be the timestamp the response was
delivered.
Consider the following example that queries the Varnish project's web server.
Note that Varnish is a popular HTTP caching server, so HTTP caching will of
course be used when serving HTTP responses from this project's web server.
testssl.sh https://varnish-cache.org/ This will typically output a HTTP clock
skew of some thousand seconds.
The patch takes into account the HTTP Age header that caching servers add to
the HTTP response to signal the response's freshness. As client-side caches
normally do not cache HTTPS requests (except maybe for "enterprise" HTTP proxy
caches that do MITM HTTPS proxying), this is mostly targeted to HTTPS websites
that employ server side HTTP caching.
Addtional polishing:
* address my comments in #2032
* add JSON field HTTP_headerAge if they exists
* output HTTP_AGE if it was detected
* do stripping of line feeds closer to where variables were set
This fixes#1834 and #1435 for branch 3.0. (3.1dev: #2047)
The --connect-timeout option had the problem that under certain circumstances
like parallel mass scanning didn't work. The culprit was that a subshell command
was used to connect to the target but the file descriptor wasn't exported.
The PR changes the logic so that the connect pre-check is still done in a subshell
If this fails it proceeds with error handling if NR_SOCKET_FAIL is above threshold.
Otherwise it just connects again.
As noted in #2016 the detection of curves in find_openssl_binary()
was not yet perfect.
This commit removes another connect call. Also it corrects the port statement
for LibreSSL-like pre-checks as port 0 generally seems to me better suited.
Inline documentation was added.
It worked so far with OpenSSL 1.0.2, 1.1.1 and 3.0 and LibreSSL 3.4.
This is for 3.0. Similar commit (a11bd1585e)
was for 3.1dev, see PR #2020 .
Same as #2014, this is for 3.0 though.
OpenSSL shows certificate serial numbers >35 with a LF (0A). Testssl.sh
just output that which makes JSON invalid and displays the LF in the terminal
too.
This PR fixes that (#2010) by adding text filters so that the
serial number is not a multiline string.
Also this PR introduces a new function: a size check of the cert serial.
Below 8 bytes the CAB Forum's lower limit is hit which says the entropy
from a CSPRNG should be at least 64 bits. It is assumed that below 8 bytes
length this requirement isn't possible to meet (needs to be clarified with
Shannon, 8 bytes seems to low to me).
The high threshold is according to RFC 5280, Section-4.1.2.2 .
See also #2013.
The output has changed, so that on the terminal the serial has one line,
SHA1 and SHA256 each one line. The new json key is "cert_serialNumberLen".
This commit provides a global variable to the RFC 6761 use of "invalid."
which WSL clients don't seem to handle very well, see #1738, #1812.
"invalid." is used as a target to find out in a couple of pre-checks what
is supported by the openssl version.
This PR reduces the number of ``openssl s_client -connect`` by a huge factor.
For the remaining invocations the OS used is being determined and if WSL is
assumed (the check is probably not 100% accurate) it uses ``127.0.0.1:0`` instead.
In (unfortunately only a few) pre-tests the response was immediate.
Also it is possible to use another target if needed by
NXCONNECT=<mytargethere>:<myport> ./testssl.sh <URL>
This is for 3.0. For 3.1dev see #1988 .
Newer configuration files from openssl may include statements
which aren't compatible with our supplied old openssl version.
This commit adds an autodetection of such a file and uses a
openssl.cnf provided by this project then.
The openssl.cnf is from a Debian Jessie package.
See also #1987
A longer while back the section ~ "Testing standard ciphers" was
renamed to "Testing cipher categories". However the internal help
didn't reflect that.
This fixes that, including an addtion to the documentation.
Note: the help still lists "-s --std, --standard" as a cmd line
switch.
Similar to #1972.
* the ignore ~/.digrc option from dig is now parsed from the builtin help
* there was a potential DNS call which is now avoided
* the +noidnout check is now parsed from the builtin help
* the OPENSSL_CONF="" in check_resolver_bins() was moved a few lines higher to avoid other errors in the terminal
* redo check for noidnout by also using the help function of dig
See also #1949
If the order of the cmdline is '-U --ids-friendly' then we need to make sure we catch --ids-friendly. Normally we do not,
see #1717. The following statement makes sure. In the do-while + case-esac loop the check for --ids-friendly will be
executed again, but it does not hurt
Newer dig versions have an option to ignore $HOME/.digrc, older
don't.
This commit adds a patch checking for the availability of
such an option and uses it by default.
If doesn't exist then still dig is used and can still lead to
wrong output. Unfortunately Debian-based distros are not very
good at this. Debian 10, Ubuntu 18.04 still use dig 9.11, whereas
Opensuse 15.2 has 9.16.
Debian 11 and Ubuntu 20.04 use that too.
Thus to be considered for the stable 3.0-branch: move
dig in the resolver functions a couple of lines down.
As mentioned in #1931 the port detection for nmap greppable files
leaves space for improvements.
Ths PR adds a pattern detection of ssl and https in the forth or fifth
parameter of an open port, so those ports will be added to a scan when
a nmap greppable output file is supplied as input to testssl.sh .
Also it does minor code adjustments to utils/gmap2testssl.sh .
Same as #1938, only for 3.0.
... see #1936.
It is ~ copied from testssl.sh. It adds a detection for the
strings ssl and https. If those run at non-standard ports but nmap
detected it, it'll show up in the output file.
This addresses a bug filed in #1935 in 3.1dev when the supplied file
has a .txt extension. In this scenario the input file was nulled
as from the input file in nmap format an internal input file was
generated which has a .txt extension, in the same directory.
The idea was to persist the file for the user.
Now, this internal input file is ephemeral and only written to $TEMPDIR.
Same as #1921, only for the stable branch
* define deny list of files when modified not to run GHA
* specitfy OS to be ubuntu-20.04 (is there a debian at all?)
* only use perl 5.26
See #1920
There was by mistake a 179 days threshold and also the error message
was wrong when HSTS was exactly set to 179 days, see #1879.
This commit sets it to 180 days and corrects the error messages on
screen.
For DNS queries a trailing dot in the variable $NODE is always fine. For
HTTP queries it is not. and causes the https request to fail.
Backport from 4f1da9b192
Also: removal of ancient CVS_REL relict in $TEMPDIR/environment.txt
