While we are thankful that Ivan Ristic permitted to use the client
data from SSLlabs, it became of bit outdated now (see #1158). Also
as sslhaf [1] was used, the data comes from HTTP traffic only.
This is a start to address it. It provides data from Android 9
(connecting to the play store, so that it is sure we don't capture
a ClientHello from an application having an own TLS stack.
Also it provides documentation how to grab data yourself, and
provide it back to testssl.sh.
Aim is at least for testssl.sh 3.0 to add Android 8 and OpenSSL 1.1.1 (@drwetter).
My hope others can assist with Safari on OSX 11 and 12. Java 10 and 11,
and a recent Opera and Edge version. (Firefox and Chrome are out of
date too)
Mail clients to follow later.
[1] https://github.com/ssllabs/sslhaf
As a result of #1225 every Linux binary needed was not allowed
to come from busybox. Which caused the Dockerfile in this repo
and the image @ dockerhub to fail.
This PR relaxes that so that busybox binaries which proved to
work can be used. A whitelist was defined.
This PR addresses the following issues raised by shellcheck:
In ../github/testssl_2.9dev_20190409b.sh line 1133:
if [[ "$BASH_VERSINFO" == 3 ]]; then
^-- SC2128: Expanding an array without an index only gives the first element.
In ../github/testssl_2.9dev_20190409b.sh line 4301:
tmpfile_handle $FUNCNAME.dd
^-- SC2128: Expanding an array without an index only gives the first element.
In ../github/testssl_2.9dev_20190409b.sh line 4388:
tmpfile_handle $FUNCNAME.dd
^-- SC2128: Expanding an array without an index only gives the first element.
In ../github/testssl_2.9dev_20190409b.sh line 4657:
tmpfile_handle $FUNCNAME$1.txt
^-- SC2128: Expanding an array without an index only gives the first element.
In ../github/testssl_2.9dev_20190409b.sh line 5327:
tmpfile_handle $FUNCNAME.${debugname}.txt
^-- SC2128: Expanding an array without an index only gives the first element.
In ../github/testssl_2.9dev_20190409b.sh line 5943:
tmpfile_handle $FUNCNAME.byID.log $tmpfile || \
^-- SC2128: Expanding an array without an index only gives the first element.
In ../github/testssl_2.9dev_20190409b.sh line 5944:
tmpfile_handle $FUNCNAME.byticket.log $tmpfile
^-- SC2128: Expanding an array without an index only gives the first element.
In ../github/testssl_2.9dev_20190409b.sh line 12410:
tmpfile_handle $FUNCNAME.dd $SOCK_REPLY_FILE
^-- SC2128: Expanding an array without an index only gives the first element.
In ../github/testssl_2.9dev_20190409b.sh line 13164:
tmpfile_handle $FUNCNAME.dd
^-- SC2128: Expanding an array without an index only gives the first element.
In ../github/testssl_2.9dev_20190409b.sh line 13284:
tmpfile_handle $FUNCNAME.dd $SOCK_REPLY_FILE
^-- SC2128: Expanding an array without an index only gives the first element.
In ../github/testssl_2.9dev_20190409b.sh line 13388:
tmpfile_handle $FUNCNAME.dd $SOCK_REPLY_FILE
^-- SC2128: Expanding an array without an index only gives the first element.
--
In ../github/testssl_2.9dev_20190409b.sh line 13801:
[[ "$DEBUG" -ge 1 ]] && echo $tls_hello_ascii >$TEMPDIR/$FUNCNAME.tls_hello_ascii${i}.txt
^-- SC2128: Expanding an array without an index only gives the first element.
When users try to reinvent the wheel and write an own dockerfile
this PR checks when binaries come from busybox -- as it is the
case with Alpine Linux.
This PR fixes#803 and emit an extra warning if the certificate
has a lifetime longer or equal of five years which happens often
on appliances with self signed certificates. (CAs do not offer
such a long certificate lifetime.) This was tested under Linux,
FreeBSD and OpenBSD. On the latter however we only check the
years as opposed to other OS where we have a finer granularity
(seconds).
On the screen there's only an output if the lifetime is too long,
using JSON or CSV formats, it is always displayed (ID: cert_validityPeriod).
Also this PR changes the ID cert_expiration_status to cert_expirationStatus.
Older FreeBSD and OpenBSD can't deal with italics characters but it output
the escape codes which could result in a different markup. This PR detects
such OS and just doesn't dsiplay the escape sequence.
Also the manpage is reflecting the change and has updates in the server
defaults and standard cipher checks section.
This PR fixes#1223 by checking whether the stapled OCSP response from the server is an error message.
Another way to fix#1223 would be to just change line 8510 to:
```
if grep -a "OCSP Response Status" <<< "$ocsp_response_status" | grep -q successful || \
[[ "$ocsp_response" =~ Responder\ Error: ]]; then
```
However, I believe this alternative would lead to confusing results, testssl.sh would print
offered, error querying OCSP responder (tryLater)
I'm not sure whether it makes sense to say "offered" when the stapled response that is provided is just an error message, but I think it is important to make clear that the error response was received from the TLS server, and that it wasn't testssl.sh that tried querying the OCSP responder.
.. for HTML check after introducing "Pre-tests"
In ~/t/32_http.t a statement failied because the debug output has deliberately a line
"Pre-test: No 128 cipher limit bug."
This and ONE additional LF are now being filtered before comparing.
Unclear why the other additional line introduced
makes no problems.
A private ~/.digrc overrides the commandline options from dig. So
we need to make sure that the output is still what is expected.
This commit addresses it by adding additional parameters, mostly
to existing awk commands so that only the fields we want are returned.
see #1220
- write to log file if there's a SERVER_SIZE_LIMIT_BUG
- write to screen if $DEBUG > 1
It's 128 + 00ff when the CISCO ACE hiccups (#1204)
Some minor improvements like removing redundant double quotes
As in #1219 reported it was possible to specify e.g.
--csv and --csvfile which was not intended.
This PR detects those conflicting options and
exists.
Also it removes 637812a022
"&& JSONHEADER=false" as it seems errorneous.
Dirk Wetter
David Cooper
Andrew Bonney