From 52d24925e0cc4f04502a6ead0e7c01598e57e279 Mon Sep 17 00:00:00 2001
From: Dirk <dirk@testssl.sh>
Date: Mon, 15 Sep 2025 17:35:37 +0200
Subject: [PATCH] > 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 \<XYZ\> but my OpenSSL command `openssl s_client -connect <host:port> <MoreParameters> </dev/null` showed no connection.
     * First of all: modern operating systems have disabled some insecure features for security reasons. As you probably can imagine testssl.sh has a different approach: it must have the capabilities to also test insecure cryptography. This is achieved either by supplying the right option to any OpenSSL version which testssl.sh finds or through bash socket programming. For OpenSSL you can temporarily re-enable some insecure crypto algorithms by using `openssl s_client -connect <host:port> -cipher 'DEFAULT@SECLEVEL=0' <MoreParameters> </dev/null`. The bad cryptography which you *can* test during runtime when supplying `-cipher 'DEFAULT@SECLEVEL=0'` to the OpenSSL version from your vendor are ciphers like NULL-MD5 and e.g. signature algorithms like RSA+SHA1. Also TLSv1 and TLSv1.1 may be enabled using this switch.
-    * 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 <host:port\> <\/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 <host:port>` 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.