testssl.sh hiccups when a user supplied after --json*/--html/-csv
a filename instead of using the corresponding --json*file/--htmlfile/-csvfile
arguments, see #1397.
This PR adresses that in a sense that it tries to detect to following
argument of --json*/--html/-csv. If that matches a suspected filename
it bails out using fatal().
This is not intended to be perfect (when the pattern doesn't match)
but catches the user error in an early stage. See also #1398
This resolves a regression introduced with IDN support (see also #1370).
* in check_resolver_bins() the determination of HAS_DIG_NOIDNOUT=true was wrong
* in get_*_record() the check for the bool variable was wrong
* in get_*_record() we shouldn't use quotes as they might be expand to a quoted arg
In cases where the probes for reading memory from the server side were not
successful (=not vulnerable) the TCP connection was not shut down properly --
leading to and undefined state and probably causing problems to a consecutive
check. The server side then assumably from time to time just didn't return
anything which caused a integration test (t/08_isHTML_valid.t) to fail
randomly.
This PR properly terminates the TCP socket connection. Also, as sending the
close notification before closing the socket was duplicated in testssl.sh
that went to a separate function.
See comment in #1375:
https://github.com/drwetter/testssl.sh/pull/1375#issuecomment-554424814
When running in debugging mode, HAS_DIG and friends was
still false as check_resolver_bins() was called too late.
This amends basically bac0f66112 .
In cases where a certificate has two CNs, the output contained
a linefeed. This replaces the line feed by a space.
This fixes a bug e.g. when supplying a proxy by a DNS name, testssl couldn't resolve the name as the HAS_ variables initialized by ``check_resolver_bins()`` was done later than ``check_proxy()``.
The patch just puts ``check_resolver_bins()`` earlier in "main"
If a server offers TLS 1.3 only and the cipher order is server side this commit changes the severity level to INFO.
Also it changes nope to no in two places
Add another pattern because the SEDs tested so far do not seem to be fine with header containing x0d x0a (CRLF) -- which is the usual case. So we also trigger on any sign on a single line which is not alphanumeric (plus _)
See #1351
PR #1336 included logic to pre-test the server side with sockets
and/or with openssl. However when the user supplied --ssl-native
sockets were never tested before. As a result ALL_FAILED_SOCKETS
was still true, so that the final eif statement complaint erroneously
that sockets didn't work but openssl does.
Also Travis complaint.
This PR fixes it by checking SSL_NATIVE to the final part of the
if statement.
One could also test sockets before and then set ALL_FAILED_SOCKETS
appropriately but that would only make sense if the socket methods
like run_robot() or run_heartbleed() would check ALL_FAILED_SOCKETS
first.
At the moment I went for this as it is easier and the case that sockets
aren't working but openssl does seems not very likely.
In order to not repeatedly call check_resolver_bins() the function
was moved to top level. As each check in check_resolver_bins now
is only executed once, it should also work faster. Each get_*_record()
now uses HAS_ variables only.
Also check_resolver_bins() contain now the check whether
idn/idn2 support is available.
Then the IDN URI conversion snipplet was moved to the final function
parse_hn_port() which does operations in the URI supplied.
This PR adds a few quotes to some arguments which when previous code
was executed properly weren't needed.
Also it improves the IDN code from @teward, so that when idn2 is
available, a conversion will be tried, and when idn is available
and/or idn2 failed, a conversion will be tried.
Finally it'll be tried to continue without conversion, hoping that
the DNS client binaries can cope with the IDN URI.
This is not good enough yet and needs to be complemented, see discussion
@ #1321.
... and thus this commit addresses #916.
It does that via a (quite) pre-test which checks for a general availabilty
of TLS 1.3 before the TLS 1.2 protocol test is being run and decides
based on that how a missing TLS 1.2 will be echoed.
Later on the complete TLS 1.3 test will be continued using the results
from the TLS 1.3 pre-test.
This commit addresses #1251 and gives a slight warning when still
using those protocols as government standards are or are at least
to expect also to deprecate those protocols. PCI DSS requires not
to use TLS 1.0 anymore and browser vendors supposedly will deprecate
TLS 1.0/1.1 next year.
This is a WIP for testing. It was committed already in May
(22ad490ea7b2868a4fd45862ca0bf8a3d8f24ea6) but somehow it was
lost.
Comments would be appeciated.
Open:
- how to treat non-HTTP protocols
- TLS 1.3 only hosts will mark the absence of TLS 1.2 as
a medium finding
In cases where TLS 1.3 is the only protocol supported by the server (as e.g.
in #1312), testssl.sh has some limits with the supplied binary.
For now (3.0) there's no perfect technical solution. This PR however improves
the verbosity what's going on and recommends to use an openssl binary
supporting TLS 1.3. And if the "secret" variable OSSL_SHORTCUT is set to true,
it automatically chooses that if available (it's a hack to do so and not
recommended. I just did it as a PoC).
In the next development we should consider probing this upfront!
Furthermore this PR removes some unnecessary quotes in double square brackets.
