From 89a0d8d2c4068e84cf73d578291e5fb5b0c66bd2 Mon Sep 17 00:00:00 2001 From: Dirk Wetter Date: Wed, 3 Sep 2025 10:51:55 +0200 Subject: [PATCH 1/4] Micro additions --- FAQ.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/FAQ.md b/FAQ.md index 6234910..e8560a6 100644 --- a/FAQ.md +++ b/FAQ.md @@ -5,16 +5,16 @@ This is a collection of frequently asked questions which should help to answer s #### Coding * Why are you using bash, everybody nowadays uses (python|Golang|Java|etc), it's much faster and modern! - * The project started in 2007 as series of OpenSSL commands in a shell script which was used for pen testing. OpenSSL then was the central part (and partly is) to do some basic operations for connections and certificates verification which would have been more tedious to implement in other programming languages. Over time the project became bigger and it in terms of resources it wasn't a viable option to convert it to (python|Golang|Java|etc). Besides, bash is easy to debug as opposed to a compiled binary. Personally, I believe its capabilities are often underestimated. + * The project started in 2007 as series of OpenSSL commands in a shell script which was used for pen testing. OpenSSL then was the central part (and partly is) to do some basic operations for connections and certificates verification which would have been more tedious to implement in other programming languages. Over time the project became bigger and it in terms of resources it wasn't a viable option to convert it to (python|Golang|Java|etc). Besides, bash is easy to debug as opposed to a compiled binary. Personally, I believe its capabilities are often underestimated, Testssl.sh contains code for de-/encoding chacha20 or gcm/ccm crypto functions --natively. * But why don't you now amend it with a (python|perl|Golang|Java|etc) function which does \ or \ much faster? - * The philosophy and the beauty of testssl.sh is that it runs *everywhere* with a minimal set of dependencies like typical Unix binaries. No worries about having a different version of libraries/ interpreter not installed. + * The philosophy and the beauty of testssl.sh is that it runs *everywhere* with a minimal set of dependencies like typical Unix binaries, plus any bash an openssl version will work. No worries about dependencies on different version of libraries not installed or using binary version A.b or interpreter C.d.. #### Runtime * I believe I spotted a false positive as testssl.sh complained about a finding \ but my OpenSSL command `openssl s_client -connect -cipher 'DEFAULT@SECLEVEL=0' -cipher 'DEFAULT@SECLEVEL=0' Date: Mon, 15 Sep 2025 17:20:54 +0200 Subject: [PATCH 2/4] Add STARTTLS + rating amend paragraphs ... and try to avoid "crypto" --- FAQ.md | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/FAQ.md b/FAQ.md index e8560a6..06b28d3 100644 --- a/FAQ.md +++ b/FAQ.md @@ -5,24 +5,34 @@ This is a collection of frequently asked questions which should help to answer s #### Coding * Why are you using bash, everybody nowadays uses (python|Golang|Java|etc), it's much faster and modern! - * The project started in 2007 as series of OpenSSL commands in a shell script which was used for pen testing. OpenSSL then was the central part (and partly is) to do some basic operations for connections and certificates verification which would have been more tedious to implement in other programming languages. Over time the project became bigger and it in terms of resources it wasn't a viable option to convert it to (python|Golang|Java|etc). Besides, bash is easy to debug as opposed to a compiled binary. Personally, I believe its capabilities are often underestimated, Testssl.sh contains code for de-/encoding chacha20 or gcm/ccm crypto functions --natively. + * The project started in 2007 as series of OpenSSL commands in a shell script which was used for pen testing. OpenSSL then was *the* mandatory part (and partly is) to do some basic operations for all connection checks which would have been more tedious to implement in other programming languages. Over time the project became bigger and it in terms of resources it wasn't a viable option to convert it to (python|Golang|Java|etc). Besides, bash is easy to debug as opposed to a compiled binary. Personally, I believe its capabilities are often underestimated, Testssl.sh contains code for de-/encoding chacha20 or gcm/ccm crypto functions --natively. + * Since quite some time any OpenSSL or LibreSSL will "do it". What cannot be tested with a particular OpenSSL or LibreSSL version will be done in bash, see enc-/ dec-functions above. And for connection checks we are using bash sockets. +* What the heck are bash sockets? + * Bash sockets are a method of network programming which happen through the shell interfaces `/dev/tcp/$IPADDRESS/$PORT` --or udp, respectively. It works also with IPv6. Here are some [randomly picked examples](https://www.xmodulo.com/tcp-udp-socket-bash-shell.html) of bash sockets. +* But why don't you now amend or replace that with a (python|perl|Golang|Java|etc) function which does \ or \ much faster? + * The philosophy and the beauty of testssl.sh is that it runs *everywhere*, independent on the OS, with a minimal set of dependencies like typical Unix binaries, plus any bash and openssl version. No worries about dependencies on different version of libraries not installed or using binary version A.b or interpreter C.d. . + + +#### Rating / Grading + +* I am testing STARTTLS and I get a poor grading/rating. Why is that?? + * STARTTLS was originally not included in the SSLlabs grading/rating which otherwise we tried to adapt 1:1. The point is that STARTTLS speaks plaintext first and upon the client's request the server may upgrade the connection to TLS on the same port. That is inherently insecure for a number of reasons and** it should be avoided whenever possible** to avoid snooping or MitM attacks. This is the reaason why its labled as it is. +* But there are standards like DNSSEC and MTA-STS which I implemented and you do not test for that!! + * They provide a band aid, mostly, for SMTP port 25. For MTA-STS there is a PR pending. DNSSEC: we'll see. But still then we cannot label the server side as secure, as every client would need to test for that. Take this communication as an example: For SMTP and mail server to mail server communication it is still common to send e-mails to a mail server if the server certificate does not validate. Also if it validates properly we can tell whether all sending mail server does that. If we would label this as secure it would give you a false sense of security. +* But what about e.g. IMAPS? + * Most of the clients probably do proper certificate validation nowadys. But still the upgrade form a plaintext connection is flawed and provides a can of worms of security problems, see e.g. [STARTTLS injection](https://nostarttls.secvuln.info/) and [Opossum](https://opossum-attack.com/). As the STARTTLS injection paper outlines: that bug dates back to 2011, when [Vietse Venema discovered a similar flaw](https://www.postfix.org/CVE-2011-0411.html). There is likely more to come. -* But why don't you now amend it with a (python|perl|Golang|Java|etc) function which does \ or \ much faster? - * The philosophy and the beauty of testssl.sh is that it runs *everywhere* with a minimal set of dependencies like typical Unix binaries, plus any bash an openssl version will work. No worries about dependencies on different version of libraries not installed or using binary version A.b or interpreter C.d.. #### Runtime * I believe I spotted a false positive as testssl.sh complained about a finding \ but my OpenSSL command `openssl s_client -connect -cipher 'DEFAULT@SECLEVEL=0' -cipher 'DEFAULT@SECLEVEL=0' <\/dev/null` which has SSLv2 and SSLv3 enabled and much more bad stuff. OTOH it doesn't support TLS 1.3 or modern elliptic curves. As said above this and any deficiency is compensated transparently either by using bash or in some cases by automagically and transparently by switching to the OpenSSL version from the vendor. * Will you backport TLS 1.3, QUIC or some other modern crypto to the supplied OpenSSL-bad version? - * That is not going to happen as it's more resource efficient use the vendor supplied version and compensate deficiencies with either the OpenSSL-bad version or with bash sockets as/where we see it fit. - * Also likely there won't be another set of compiled binaries --unless the sky falls on our heads. - + * That is not going to happen as it's more resource efficient use the vendor supplied version and compensate deficiencies with either the OpenSSL-bad version or with bash sockets as/where we see it fit. + * Also likely there won't be another set of compiled binaries --unless the sky falls on our heads. * Where can I find infos about "your" OpenSSL version? - * Source code, documentation and license see [here](https://github.com/testssl/openssl-1.0.2.bad). You may use it for testing. But don't use it in production on a server or as a client in any other context like testssl.sh! + * Source code, documentation and license see [here](https://github.com/testssl/openssl-1.0.2.bad). You may use it for testing. But don't use it in production on a server or as a client in any other context like testssl.sh! + -* What the heck are bash sockets? - * Bash sockets are a method of network programming which happen through the shell interfaces `/dev/tcp/$IPADDRESS/$PORT` --or udp, respectively. It works also with IPv6. Here are some [randomly picked examples](https://www.xmodulo.com/tcp-udp-socket-bash-shell.html) of bash sockets. From f36462b14a6281883fef2dad95ba70e6a3a7e81c Mon Sep 17 00:00:00 2001 From: Dirk Date: Mon, 15 Sep 2025 17:26:06 +0200 Subject: [PATCH 3/4] fix spell checking --- FAQ.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/FAQ.md b/FAQ.md index 06b28d3..968eecd 100644 --- a/FAQ.md +++ b/FAQ.md @@ -16,11 +16,11 @@ This is a collection of frequently asked questions which should help to answer s #### Rating / Grading * I am testing STARTTLS and I get a poor grading/rating. Why is that?? - * STARTTLS was originally not included in the SSLlabs grading/rating which otherwise we tried to adapt 1:1. The point is that STARTTLS speaks plaintext first and upon the client's request the server may upgrade the connection to TLS on the same port. That is inherently insecure for a number of reasons and** it should be avoided whenever possible** to avoid snooping or MitM attacks. This is the reaason why its labled as it is. + * STARTTLS was originally not included in the SSLlabs grading/rating which otherwise we tried to adapt 1:1. The point is that STARTTLS speaks plaintext first and upon the client's request the server may upgrade the connection to TLS on the same port. That is inherently insecure for a number of reasons and** it should be avoided whenever possible** to avoid snooping or MitM attacks. This is the reaason why its labeled as it is. * But there are standards like DNSSEC and MTA-STS which I implemented and you do not test for that!! * They provide a band aid, mostly, for SMTP port 25. For MTA-STS there is a PR pending. DNSSEC: we'll see. But still then we cannot label the server side as secure, as every client would need to test for that. Take this communication as an example: For SMTP and mail server to mail server communication it is still common to send e-mails to a mail server if the server certificate does not validate. Also if it validates properly we can tell whether all sending mail server does that. If we would label this as secure it would give you a false sense of security. * But what about e.g. IMAPS? - * Most of the clients probably do proper certificate validation nowadys. But still the upgrade form a plaintext connection is flawed and provides a can of worms of security problems, see e.g. [STARTTLS injection](https://nostarttls.secvuln.info/) and [Opossum](https://opossum-attack.com/). As the STARTTLS injection paper outlines: that bug dates back to 2011, when [Vietse Venema discovered a similar flaw](https://www.postfix.org/CVE-2011-0411.html). There is likely more to come. + * Most of the clients probably do proper certificate validation nowadays. But still the upgrade form a plaintext connection is flawed and provides a can of worms of security problems, see e.g. [STARTTLS injection](https://nostarttls.secvuln.info/) and [Opossum](https://opossum-attack.com/). As the STARTTLS injection paper outlines: that bug dates back to 2011, when [Vietse Venema discovered a similar flaw](https://www.postfix.org/CVE-2011-0411.html). There is likely more to come. From 52d24925e0cc4f04502a6ead0e7c01598e57e279 Mon Sep 17 00:00:00 2001 From: Dirk Date: Mon, 15 Sep 2025 17:35:37 +0200 Subject: [PATCH 4/4] > was a problem trying to get it right in GiHub MD and retext --- FAQ.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FAQ.md b/FAQ.md index 968eecd..ec059d7 100644 --- a/FAQ.md +++ b/FAQ.md @@ -28,7 +28,7 @@ This is a collection of frequently asked questions which should help to answer s * I believe I spotted a false positive as testssl.sh complained about a finding \ but my OpenSSL command `openssl s_client -connect -cipher 'DEFAULT@SECLEVEL=0' <\/dev/null` which has SSLv2 and SSLv3 enabled and much more bad stuff. OTOH it doesn't support TLS 1.3 or modern elliptic curves. As said above this and any deficiency is compensated transparently either by using bash or in some cases by automagically and transparently by switching to the OpenSSL version from the vendor. + * There is other bad cryptography though which you can't test this way, e.g. ancient SSL protocols. Modern OS supply OpenSSL binaries which have [SSLv2 and SSLv3 disabled in the source code or at least when compiling](https://docs.openssl.org/3.3/man7/ossl-guide-tls-introduction/#what-is-tls) which you can't re-enable during runtime. You might get a bit further with the by us supplied OpenSSL-bad version like `OPENSSL_CONF='' ./bin/openssl.Linux.x86_64 s_client -connect ` which has SSLv2 and SSLv3 enabled and much more bad stuff. OTOH it doesn't support TLS 1.3 or modern elliptic curves. As said above this and any deficiency is compensated transparently either by using bash or in some cases by automagically and transparently by switching to the OpenSSL version from the vendor. * Will you backport TLS 1.3, QUIC or some other modern crypto to the supplied OpenSSL-bad version? * That is not going to happen as it's more resource efficient use the vendor supplied version and compensate deficiencies with either the OpenSSL-bad version or with bash sockets as/where we see it fit. * Also likely there won't be another set of compiled binaries --unless the sky falls on our heads.