Despite the fact google doesn't support RC4 ciphers, testssl.sh called
sslv2_sockets(). Google answered with a >= TLS alert. Building a sum then
failed then in sslv2_sockets().
This fixes sslv2_sockets() and introduces count_chars() as a helper function
(tested also under old FreeBSD to make sure it works under MacOSX).
Also it adds a shortcut: if we are sure we don't have sslv2 we don't need
to test any RC4 SSLv2 ciphers
This fixes#1754 by avoiding further string operations if the SSLv2 socket reply is empty as bash 5.1 seems to have a problem with that. The fix is done in sslv2_sockets() .
Also sslv2 is not being used in run_freak() if known not to be supported.
Server side closed the connection but openssl retrieved
a zero exit code. In addition now we look for "closed"
and if that was returned from the server we label it
as not vulnerable.
This fixes#1725.
Same fix as for 3.1dev, see #1726
When testssl.sh is called with an unknown option it prints something like:
0: unrecognized option "--option"
It should be printing the name of the program rather than "0". This commit fixes that.
.. see also #1559.
It "mkdirs" the needed etc and bin directories first, then copies
stuff over. It also reduces a few layers.
Also it corrects a mistake in the Readme.md (docker exec --> run)
... and at the same time allow correct local builds --
the default branch is 3.1dev at the moment.
It still clones the repo from github which isn't
needed. A pure copy command would be the best. However
it might cause other problems.
See also #1559
* outlook to 3.0.2 (~tomorrow), remove ref. to rc
* fix docker cmd line (albeit there's still a problem w dockerhub)
* label 3.1dev it as a ~rolling release
There was a empty variable in determine_optimal_proto() which prevented to save STARTTLS_OPTIMAL_PROTO. This is fixed.
The buffers and return codes for XMPP in starttls_io() were under not every
circumstances correct. This fixes those cases and making that in general more
robust (hopefully).
As noted in #1605 the brotli compression check was missing. So hosts
which didn't offer gzip deflate or compress but brotli seemed to
be fine but they shoould have been labled as potentially VULNERABLE.
This also fixes a bug: The HTTP header returned was only checking
for case-sensitive "Content-Encoding". RFC 2616 states in 4.2
(Message Headers): "Field names are case-insensitive"
