The expression 'grep -aw "Public-Key:"' hiccuped on the colon
under OpenBSD, so that any bitsize on a certificate had wrong
values, see #1425. (FreeBSD was fine)
This PR fixes that. It updates the expression by using awk and
bash internal functions.
The same problem occured in run_robot(). The strong typing of
pubkeybits had to be relaxed to a dynamic typing, unless we
choose to define a second string variable.
* old OpenBSD kinda works
* let's encrypt section moved so that OpenBSD can use it too
* Days are wrong
* Date format is not the same as with e.g. GNUdate (but should be)
* variables y m d not declared
* date warning for openbsd completely missing
As noted in #1418 LLMNR (Link-Local Multicast Name Resolution)
resolution times out when using x as an argument to "-connect".
This commit fixes that by replacing "-connect x" by "-connect invalid."
which is supposedly also generally more "DNS query friendly", see
https://tools.ietf.org/html/rfc6761#section-6.4 .
In addition this commit adds a check in get_common_prime() whether
the openssl version used has pkey support. If not with old openssl
versions and previously testssl.sh terminated after presenting garbledoutput.
(This was found as tested how very old version of openssl versions
handle "-connect invalid.")
If the server is known not to support TLS 1.3 (as well as TLS 1.2, TLS 1.1, and TLS 1), then mention TLS 1.3 in the list of not supported protocols. While lack of TLS 1.3 support is not part of the reason that no fallback is possible, it is part of the reason that the result is reported as prln_svrty_high.
If $high_proto is set to something other than SSLv3, support for SSLv3 will not have been determined by determine_optimal_sockets_params(), but it may have been determined later (e.g., by run_protocols()). So, this commit changes the loop to always check for SSLv3 support (without calling "$OPENSSL s_client" if $HAS_SSL3 is false). The check for whether the fallback test can be performed is moved until after the loop
This PR fixes a couple of places where "$OPENSSL s_client" is called with "-ssl3" even if SSLv3 is not supported.
The fix in ciphers_by_strength() is easy, as the issue only occurs if "$using_sockets" is true. If SSLv3 (or TLSv1.3) is not supported, then testing using "$OPENSSL s_client" is skipped and all of the supported ciphers are found using tls_sockets().
The fix for run_tls_fallback_scsv() is more complicated. While it is easy to avoid calling "$OPENSSL s_client" with "-ssl3" if SSLv3 is not supported, it is not easy to determine the correct message to present to the user if support for SSLv3 (and possibly also TLSv1.3) is unknown.
For the case in which $high_proto cannot be set, I believe that I have covered all of the possibilities, but an not sure if the correct message/rating is used in every case.
For the case in which it is not possible to determine whether SSLv3 is the $low_proto, more could be done. If $high_proto is TLS 1.1 or TLS 1, then this PR is okay, as it is possible that SSLv3 would be the fallback protocol, but there is no way to tell. However, it seems unlikely that a server would support TLS 1.2 and SSLv3, but not TLS 1.1 or TLS 1. So, perhaps if $high_proto is TLS 1.2 and the server does not support TLS 1.1 or TLS 1, it should just be assumed that SSLv3 is not supported, even if it cannot be tested.
At the moment, testssl.sh does not correctly derive the handshake traffic keys in the case that the server responds to the initial ClientHello with a HelloRetryRequest. The handshake traffic keys are computed incorrectly because the wrong messages are provided to derive-handshake-traffic-keys() for input to the Transcript-Hash calculation:
* TLS_CLIENT_HELLO is not updated to contain the value of the second ClientHello, and so the first ClientHello is being provided to derive-handshake-traffic-keys() as both the first and the second ClientHello.
* In middlebox compatibility mode the server may send a dummy ChangeCipherSpec message immediately after the HelloRetryRequest. Since it is part of the server's response to the initial ClientHello, the ChangeCipherSpec message is included in the $hrr that is sent to derive-handshake-traffic-keys(), but it should not be included in the computation of the Transcript-Hash.
This PR fixes the above two problems by updating TLS_CLIENT_HELLO when a second ClientHello is sent and by removing any ChangeCipherSpec message (140303000101) from the end of the server's initial response.
* Severity of RC4 in run_cipherlists() is now high as everywhere else
* Same for RC2 and DES. Only Export, NULL and ADH remain critical
* 3DES and IDEA in run_cipherlists() is now medium (see #1393)
* CBC3 SEED 3DES IDEA added in pr_cipher_quality()
* MD5 added to pr_cipher_quality() and labled as high
* double RC2 switch statemnet removed in pr_cipher_quality()
* timeouts are not default anymore but need a cmdline param (or ENV param)
* check whether "timeout" exists
Also:
* allow OPENSSL_TIMEOUT to be passed via ENV similar to others
* replace timeout variable in run_robot() by robottimeout, to avoid
misunderstandings by a human
ToDos: see inline. Mainly if timeout isn't available, testssl.sh doesn't
work.
Not to self: help function still says 60 second is default.
When printing a long HTTP security header, this commit causes every row after the first one to be indented by two additional spaces. In the case of very long headers, this extra indentation makes it a little easier for readers to see where the next security header begins.
When printing out HTTP security headers, run_security_headers() uses out_row_aligned_max_width(), since some headers are very long and need to be wrapped. At the moment, however, the first line is too long. The problem is that while "$header $HEADERVALUE" is printed in the indented area, only $HEADERVALUE is passed to out_row_aligned_max_width().
This PR fixes the problem by passing "$header $HEADERVALUE" to out_row_aligned_max_width() so that the the first line is wrapped at the correct place.
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
Dirk Wetter
Fabrice Bacchella
Vitalii Tverdokhlib
David Cooper
Max Wittig