Prior to this commit, the code accepts both the --cafile and the
--capath options, as that's how it's always behaved. This patch corrects
that, refusing to proceed if the options are provided.
Technically, openssl permits the use of both the -CAfile and -CApath
options. However, cipherscan itself can only make use of one of the two
options, and does not currently support "one or both" scenarios.
So this patch ensures that users are not caught unaware when they
specify --capath and --cafile and the script refuses to honor the
latter.
For unknown reasons, while we previously supported --capath we did not
support --cafile. This forces the --cafile autodetection logic to run
every time, unnecessarily, when we have a specific file in mind to use.
This patch relocates the -CAfile autodetection logic to run *only if*
the --cafile parameter is not provided. If it is not provided, the
autodetection logic occurs precisely as before.
This patch declines to address what happens if both --capath and
--cafile are passed. The previous logic already ensured that the CA file
was *always* set, and then only sometimes was the CA path set. The new
logic maintains that behavior precisely, reserving logic flow changes
for a separate commit.
This catches instances where the wrong openssl binary is selected (for
instance, if uname -s is neither Darwin nor Linux) and serves as a
simple up-front test to make sure that openssl is working before we
proceed further into the script.
The crude_grep function served only to perform a simple substring check
against the output of openssl -help. So, instead of running the command
each time, iterating its output line by line, and checking for the
substring within it, this simply caches the -help output at startup and
uses $help =~ substring to produce the same result in a single pass.
In cipherscan line 451:
for ((i=0; i<$certificate_count; i=i+1 )); do
^-- SC2004: $/${} is unnecessary on arithmetic variables.
In cipherscan line 603:
cipherbenchms="$((t/1000/$BENCHMARKITER))"
^-- SC2004: $/${} is unnecessary on arithmetic variables.
In cipherscan line 13:
REALPATH=$(dirname $0)
^-- SC2086: Double quote to prevent globbing and word splitting.
In cipherscan line 15:
readlink -f $0 &>/dev/null && REALPATH=$(dirname $(readlink -f $0))
^-- SC2086: Double quote to prevent globbing and word splitting.
^-- SC2046: Quote this to prevent word splitting.
^-- SC2086: Double quote to prevent globbing and word splitting.
In cipherscan line 46:
if [[ -e $(dirname $0)/openssl.cnf ]]; then
^-- SC2086: Double quote to prevent globbing and word splitting.
In cipherscan line 47:
export OPENSSL_CONF="$(dirname $0)/openssl.cnf"
^-- SC2155: Declare and assign separately to avoid masking return values.
^-- SC2086: Double quote to prevent globbing and word splitting.
In cipherscan line 60:
CACERTS="$(dirname $0)/ca-bundle.crt"
^-- SC2086: Double quote to prevent globbing and word splitting.
In cipherscan line 941:
verbose "Server supported curves: ${tmp_curves[@]}"
^-- SC2145: Argument mixes string and array. Use * or separate argument.
In cipherscan line 968:
verbose "ephem_data: ${ephem_data[@]}"
^-- SC2145: Argument mixes string and array. Use * or separate argument.
Bash implements a backwards-compatible sh syntax for [ .. ], which
handles undef variables poorly. Use [[ .. ]] instead, to take full
advantage of the Bash improvements to the comparison brackets.
because subprocess returns `bytes` in Python 3
we need to interpret them to characters, which are needed by json
input and string parsing
fixes#69, #71
buggy servers may choke on large ClientHello's, TLSv1.2 ClientHello's,
etc. try to detect such failures and report them
among tried connections are TLS1.2, TLS1.1, TLS1.0 and SSLv3 with
ability to downgrade to lower protocol versions as well as a size
limited client hello, both TLS1.2 and TLS1.0 version
EXP is self explanatory - export grade
DES-CBC3-MD5 is available only in SSLv2 - not secure
RC4-64-MD5 is also a weakened version (though not marked as export grade)
It's unlikely that there are SSLv2 only servers on the 'net, all
that were detected as such and I've checked actually are intolerant
to low placement of RC4 in cipher order or intolerant to large client
hello in general. In case we detect issues with the server, switch to
reduced cipher set and run the test again that should give better results
for about 3% of hosts
