testssl.sh
testssl.sh copied to clipboard
drwetter
How we'll deal with remaining issues of TLS 1.3 only hosts?
Please make sure that you provide enough information so that we understand what your issue is about.
- uname -a
$ uname -a
Linux pentoo 5.2.11-pentoo #1 SMP Thu Sep 5 10:59:13 CEST 2019 x86_64 Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz GenuineIntel GNU/Linux
- testssl version from the banner: testssl.sh -b 2>/dev/null | head -4 | tail -2
$ testssl.sh -b 2>/dev/null | head -4 | tail -2
testssl.sh 3.0rc5 from https://testssl.sh/dev/
- git log | head -1 (if running from git repo)
N/A
- openssl version used by testssl.sh: testssl.sh -b 2>/dev/null | awk -F':' '/openssl/ { print $2}'
$ testssl.sh -b 2>/dev/null | awk -F':' '/openssl/ { print $2}'
/usr/bin/openssl-bad
- steps to reproduce: testssl.sh or docker command line, if possible incl. host
Scan a TLS 1.3 (final) only host. Im this case:
nginx-full-1.14.2-2+deb10u1 openssl-1.1.1c-1
- what exactly was happening, output is needed
$ testssl.sh foo.bar
###########################################################
testssl.sh 3.0rc5 from https://testssl.sh/dev/
This program is free software. Distribution and
modification under GPLv2 permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
Please file bugs @ https://testssl.sh/bugs/
###########################################################
Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~197 ciphers]
on pentoo:/usr/bin/openssl-bad
(built: "May 2 21:19:52 2019", platform: "linux-x86_64")
Start 2019-09-07 21:42:26 -->> 123.123.123.123:443 (foo.bar) <<--
Further IP addresses: 123:123:123:123::123
rDNS (123.123.123.123): foo.bar.
Service detected: Couldn't determine what's running on port 443, assuming no HTTP service => skipping all HTTP checks
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 not offered
TLS 1.1 not offered
TLS 1.2 not offered
TLS 1.3 offered (OK): final
NPN/SPDY not offered
ALPN/HTTP2 not offered
Testing cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES, RC[2,4] (w/o export) not offered (OK)
Triple DES Ciphers / IDEA not offered (OK)
Average: SEED + 128+256 Bit CBC ciphers not offered
Strong encryption (AEAD ciphers) offered (OK)
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
PFS is offered (OK) TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
Elliptic curves offered: secp384r1 X25519
Testing server preferences
Has server cipher order? yes (OK)
Negotiated protocol TLSv1.3
Negotiated cipher TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Cipher order
TLSv1.3: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256
Oops: openssl s_client connect problem
Testing server defaults (Server Hello)
TLS extensions (standard) "supported versions/#43" "key share/#51"
"supported_groups/#10" "status request/#5"
Session Ticket RFC 5077 hint no -- no lifetime advertised
SSL Session ID support yes
Session Resumption Tickets no, ID resumption test failed
TLS clock skew Random values, no fingerprinting possible
Signature Algorithm SHA256 with RSA
Server key size RSA 4096 bits
Server key usage Digital Signature, Key Encipherment
Server extended key usage TLS Web Server Authentication, TLS Web Client Authentication
Serial / Fingerprints 04E5B544A566B6EF08FB2DD9D43CC37F4F61 / SHA1 00741D550E9F9D4AF343DD9FADD0CF7F74B1E75B
SHA256 755FB494A5120A10A65C79736FF466DFB1417409DEC924C2AF31423A2585E48E
Common Name (CN) foo.bar
subjectAltName (SAN) foo.bar www.foo.bar
Issuer Let's Encrypt Authority X3 (Let's Encrypt from US)
Trust (hostname) Ok via SAN and CN (same w/o SNI)
Chain of trust Ok
EV cert (experimental) no
"eTLS" (visibility info) not present
Certificate Validity (UTC) 73 >= 30 days (2019-08-12 10:00 --> 2019-11-10 09:00)
# of certificates provided 2
Certificate Revocation List --
OCSP URI http://ocsp.int-x3.letsencrypt.org
OCSP stapling offered, not revoked
OCSP must staple extension --
DNS CAA RR (experimental) available - please check for match with "Issuer" above: issue=letsencrypt.org
Certificate Transparency yes (certificate extension)
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. -- (applicable only for HTTPS)
ROBOT Server does not support any cipher suites that use RSA key transport
Secure Renegotiation (CVE-2009-3555)
Fatal error: repeated openssl s_client connect problem, doesn't make sense to continue
Consider increasing MAX_OSSL_FAIL (currently: 2)
- what did you expect instead?
I expected testssl.sh to not have the above problems, such as detecting the server is running an HTTP server, and not have the ambiguous "openssl s_client connect problem" errors
Hi,
you are right. In cases like yours the openssl supplied cannot connect in the very few instances left where openssl is needed.
Looking at your system you were using for testing you might as well use the openssl from your OS (--openssl <os_openssl>).
For the time being the output could be more verbose though. Let me check whether I can do something on that direction.
Thx, Dirk
Hi @gkroon ,
the output should be better now. As said in cases where the system has a better matching OpenSSL to the server side like yours you're better off running it with e.g. --openssl /usr/bin/openssl. A hackish shortcut with the PR merged is using OSSL_SHORTCUT=true ./testssl.sh <CMDLINE>. That tries to use after all protocols tested to use /usr/bin/openssl.
For 3.0 this is what I can do. More to follow in 3.1.
Thx, Dirk
Thanks, @drwetter! Sadly my system's openssl is still using the 1.0.2 branch, without TLS 1.3. But perhaps other people are reading this and are using the 1.1.0 branch that do have the option to use TLS 1.3.
Looking at the system name and kernel revision it pretty much looks like your system has openssl 1.1.1 in /usr/bin/openssl, so
OSSL_SHORTCUT=true ./testssl.sh <CMDLINE> or (better) testssl.sh --openssl /usr/bin/openssl. <CMDLINE>
should work for you.
If not you'll see at least clearer messages what the problem is. Then: bear with us for next version
The version of OpenSSL that is pre-built and distributed with testssl.sh should be capable of handling TLS 1.3, I believe.
So, I would think that would be the version you would want to use by default in your testing, instead of the system provided version of OpenSSL.
There's no easy way providing support for TLS 1.3 AND (SSLv2 and some curves and ciphers).
But there's also hope that OpenSSL 1.1.1 will become common on the client side, so that can be used then for the few cases needed.
Analysis and a decision what's best will be done for 3.1.
is there any update regarding this issue? If necessary, I can provide various outputs with evidence of the problem.
TL;DR: not, atm it's left to the user. (--openssl=<myopensslbinarywithtls1.3>)
There were two minor steps. @dcooper16 extended his TLS 1.3 implementation in sockets, so that partly a full handshake is possible (see e.g. #1476 and #1484). And: internally we'll check whether there's a newer openssl version available which was needed for STARTTLS injection. For the latter: except this feature we don't make use of it - yet. Reason: Atm it is not clear yet what would be missing on "the other bad side" if we switch completely over to a TLS 1.3 supported binary. And a mixture of using both requires "some" work.
To see a more severe problem with this, I have set up a host with far more limited / modern cipher suites.
docker run --rm -ti drwetter/testssl.sh https://reelix.h4ck.me/
###########################################################
testssl.sh 3.2rc2 from https://testssl.sh/dev/
This program is free software. Distribution and
modification under GPLv2 permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
Please file bugs @ https://testssl.sh/bugs/
###########################################################
Using "OpenSSL 1.0.2-bad (1.0.2k-dev)" [~183 ciphers]
on 09e3d06d655c:/home/testssl/bin/openssl.Linux.x86_64
(built: "Sep 1 14:03:44 2022", platform: "linux-x86_64")
Start 2022-12-12 13:36:56 -->> 129.151.191.150:443 (reelix.h4ck.me) <<--
rDNS (129.151.191.150): --
Using the included version of OpenSSL (Or running testssl through docker, as I have done here), the script hangs at the specific location. The specific version of OpenSSL cannot connect to this site at all as it is using cipher suites only compatible with version 1.1.1c or higher (I was attempting to hit full 100's on https://www.ssllabs.com/ssltest/ for fun), and illustrates a case where testssl hangs indefinately.
Hi @reelix,
for me (container or not) it doesn't hang but prompts
This somehow was falling off the table. I labeled this now as important and one thing which need to be addressed in the upcoming release. It was intended to automatically switch to /usr/bin/openssl when available in cases like yours.
For the time being --openssl=/usr/bin/openssl will help you
Looking at the system name and kernel revision it pretty much looks like your system has openssl 1.1.1 in
/usr/bin/openssl, so
OSSL_SHORTCUT=true ./testssl.sh <CMDLINE>or (better)testssl.sh --openssl /usr/bin/openssl. <CMDLINE>should work for you.
If not you'll see at least clearer messages what the problem is. Then: bear with us for next version
Hi @drwetter For the time being OSSL_SHORTCUT=true works fine thank you. Just a remaining issue in that case the pretty-JSON output is not a valid JSON document anymore. see below:
{
"clientProblem1" : [
{
"id" : "engine_problem",
"severity" : "WARN",
"finding" : "No engine or GOST support via engine with your /home/testssl/bin/openssl.Linux.x86_64"
}
],
"Invocation" : "testssl.sh --quiet -E --mapping no-openssl -S -U -g --connect-timeout 5 --openssl-timeout 5 --warnings batch --openss
"at" : "241c0d5512fc:/home/testssl/bin/openssl.Linux.x86_64",
"version" : "3.0.8 from ",
"openssl" : "OpenSSL 1.0.2-bad from Sep 1 14:03:44 2022",
"startTime" : "1686146329",
"scanResult" : [
"clientProblem2" : [
{
"id" : "engine_problem",
"severity" : "WARN",
"finding" : "No engine or GOST support via engine with your /usr/bin/openssl"
}
],
{
"targetHost" : "gratin",
"ip" : "10.193.5.196",
"port" : "443",
as you can see the key:value ("clientProblem2":[]) in the array (scanResult). looking forward for release 3.1
Jumping on this train: would it be possible to provide an OpenSSL version (or API-compatible alternative) directly with the Docker image?
