Git/testssl.sh
1
0
Fork 0
mirror of https://github.com/drwetter/testssl.sh.git synced 2025-09-05 19:42:54 +02:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch '3.2' into 3.3dev

Browse Source
This commit is contained in:
Dirk Wetter
2025-07-03 09:00:16 +02:00
parent 4b71d0e2ce 4b5409122c
commit 6173d80ca2
5 changed files with 19 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
.github/workflows/docker-3.2.yml vendored
View File

@ -8,8 +8,8 @@ on:
# Every week at 8am on Mondays, publish the 3.2 branch: # Every week at 8am on Mondays, publish the 3.2 branch:
# NOTE: `schedule` event is only triggered for the default branch: # NOTE: `schedule` event is only triggered for the default branch:
# https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule # https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule
schedule: # schedule:
- cron: "0 8 * * 1" # - cron: "0 8 * * 1"
env: env:
GIT_BRANCH: "3.2" GIT_BRANCH: "3.2"

2
doc/testssl.1
View File

@ -96,7 +96,7 @@ A typical internal conversion to testssl\.sh file format from nmap's grep(p)able
.P .P
\fB\-\-ssl\-native\fR Instead of using a mixture of bash sockets and a few openssl s_client connects, testssl\.sh uses the latter (almost) only\. This is faster but provides less accurate results, especially for the client simulation and for cipher support\. For all checks you will see a warning if testssl\.sh cannot tell if a particular check cannot be performed\. For some checks however you might end up getting false negatives without a warning\. Thus it is not recommended to use\. It should only be used if you prefer speed over accuracy or you know that your target has sufficient overlap with the protocols and cipher provided by your openssl binary\. \fB\-\-ssl\-native\fR Instead of using a mixture of bash sockets and a few openssl s_client connects, testssl\.sh uses the latter (almost) only\. This is faster but provides less accurate results, especially for the client simulation and for cipher support\. For all checks you will see a warning if testssl\.sh cannot tell if a particular check cannot be performed\. For some checks however you might end up getting false negatives without a warning\. Thus it is not recommended to use\. It should only be used if you prefer speed over accuracy or you know that your target has sufficient overlap with the protocols and cipher provided by your openssl binary\.
.P .P
\fB\-\-openssl <path_to_openssl>\fR testssl\.sh tries very hard to find automagically the binary supplied (where the tree of testssl\.sh resides, from the directory where testssl\.sh has been started from, etc\.)\. If all that doesn't work it falls back to openssl supplied from the OS (\fB$PATH\fR)\. With this option you can point testssl\.sh to your binary of choice and override any internal magic to find the openssl binary\. (Environment preset via \fBOPENSSL=<path_to_openssl>\fR)\. \fB\-\-openssl <path_to_openssl>\fR testssl\.sh tries first very hard to find the binary supplied (where the tree of testssl\.sh resides, from the directory where testssl\.sh has been started from, etc\.)\. If all that doesn't work it falls back to openssl supplied from the OS (\fB$PATH\fR)\. With this option you can point testssl\.sh to your binary of choice and override any internal magic to find the openssl binary\. (Environment preset via \fBOPENSSL=<path_to_openssl>\fR)\. Depending on your test parameters it could be faster to pick the OpenSSL version which has a bigger overlap in terms of ciphers and protocols with the target\. Also, when testing a modern server, OpenSSL 3\.X is faster than older OpenSSL versions, or on MacOS 18\. as opposed to the provided LibreSSL version\.
.SS "TUNING OPTIONS" .SS "TUNING OPTIONS"
\fB\-\-bugs\fR does some workarounds for buggy servers like padding for old F5 devices\. The option is passed as \fB\-bug\fR to openssl when needed, see \fBs_client(1)\fR, environment preset via \fBBUGS="\-bugs"\fR (1x dash)\. For the socket part testssl\.sh has always workarounds in place to cope with broken server implementations\. \fB\-\-bugs\fR does some workarounds for buggy servers like padding for old F5 devices\. The option is passed as \fB\-bug\fR to openssl when needed, see \fBs_client(1)\fR, environment preset via \fBBUGS="\-bugs"\fR (1x dash)\. For the socket part testssl\.sh has always workarounds in place to cope with broken server implementations\.
.P .P

2
doc/testssl.1.html
View File

@ -210,7 +210,7 @@ The same can be achieved by setting the environment variable <code>WARNINGS</cod
<p><code>--ssl-native</code> Instead of using a mixture of bash sockets and a few openssl s_client connects, testssl.sh uses the latter (almost) only. This is faster but provides less accurate results, especially for the client simulation and for cipher support. For all checks you will see a warning if testssl.sh cannot tell if a particular check cannot be performed. For some checks however you might end up getting false negatives without a warning. Thus it is not recommended to use. It should be only used if you prefer speed over accuracy or you know that your target has sufficient overlap with the protocols and cipher provided by your openssl binary.</p> <p><code>--ssl-native</code> Instead of using a mixture of bash sockets and a few openssl s_client connects, testssl.sh uses the latter (almost) only. This is faster but provides less accurate results, especially for the client simulation and for cipher support. For all checks you will see a warning if testssl.sh cannot tell if a particular check cannot be performed. For some checks however you might end up getting false negatives without a warning. Thus it is not recommended to use. It should be only used if you prefer speed over accuracy or you know that your target has sufficient overlap with the protocols and cipher provided by your openssl binary.</p>
<p><code>--openssl &lt;path_to_openssl&gt;</code> testssl.sh tries very hard to find automagically the binary supplied (where the tree of testssl.sh resides, from the directory where testssl.sh has been started from, etc.). If all that doesn't work it falls back to openssl supplied from the OS (<code>$PATH</code>). With this option you can point testssl.sh to your binary of choice and override any internal magic to find the openssl binary. (Environment preset via <code>OPENSSL=&lt;path_to_openssl&gt;</code>).</p> <p><code>--openssl &lt;path_to_openssl&gt;</code> testssl.sh tries first very hard to find the binary supplied (where the tree of testssl.sh resides, from the directory where testssl.sh has been started from, etc.). If all that doesn't work it falls back to openssl supplied from the OS (<code>$PATH</code>). With this option you can point testssl.sh to your binary of choice and override any internal magic to find the openssl binary. (Environment preset via <code>OPENSSL=&lt;path_to_openssl&gt;</code>). Depending on your test parameters it could be faster to pick the OpenSSL version which has a bigger overlap in terms of ciphers and protocols with the target. Also, when testing a modern server, OpenSSL 3.X is faster than older OpenSSL versions, or on MacOS 18, as opposed to the provided LibreSSL version.</p>
<h3 id="TUNING-OPTIONS">TUNING OPTIONS</h3> <h3 id="TUNING-OPTIONS">TUNING OPTIONS</h3>

2
doc/testssl.1.md
View File

@ -132,7 +132,7 @@ The same can be achieved by setting the environment variable `WARNINGS`.
`--ssl-native` Instead of using a mixture of bash sockets and a few openssl s_client connects, testssl.sh uses the latter (almost) only. This is faster but provides less accurate results, especially for the client simulation and for cipher support. For all checks you will see a warning if testssl.sh cannot tell if a particular check cannot be performed. For some checks however you might end up getting false negatives without a warning. Thus it is not recommended to use. It should only be used if you prefer speed over accuracy or you know that your target has sufficient overlap with the protocols and cipher provided by your openssl binary. `--ssl-native` Instead of using a mixture of bash sockets and a few openssl s_client connects, testssl.sh uses the latter (almost) only. This is faster but provides less accurate results, especially for the client simulation and for cipher support. For all checks you will see a warning if testssl.sh cannot tell if a particular check cannot be performed. For some checks however you might end up getting false negatives without a warning. Thus it is not recommended to use. It should only be used if you prefer speed over accuracy or you know that your target has sufficient overlap with the protocols and cipher provided by your openssl binary.
`--openssl <path_to_openssl>` testssl.sh tries very hard to find automagically the binary supplied (where the tree of testssl.sh resides, from the directory where testssl.sh has been started from, etc.). If all that doesn't work it falls back to openssl supplied from the OS (`$PATH`). With this option you can point testssl.sh to your binary of choice and override any internal magic to find the openssl binary. (Environment preset via `OPENSSL=<path_to_openssl>`). `--openssl <path_to_openssl>` testssl.sh tries first very hard to find the binary supplied (where the tree of testssl.sh resides, from the directory where testssl.sh has been started from, etc.). If all that doesn't work it falls back to openssl supplied from the OS (`$PATH`). With this option you can point testssl.sh to your binary of choice and override any internal magic to find the openssl binary. (Environment preset via `OPENSSL=<path_to_openssl>`). Depending on your test parameters it could be faster to pick the OpenSSL version which has a bigger overlap in terms of ciphers protocols with the target. Also, when testing a modern server, OpenSSL 3.X is faster than older OpenSSL versions, or on MacOS 18, as opposed to the provided LibreSSL version.
### TUNING OPTIONS ### TUNING OPTIONS

23
testssl.sh
View File

@ -22468,6 +22468,9 @@ sclient_auth() {
# (3) This is not a TLS/SSL enabled server. # (3) This is not a TLS/SSL enabled server.
# This information can be used by determine_optimal_proto() to help distinguish between a server # This information can be used by determine_optimal_proto() to help distinguish between a server
# that is not TLS/SSL enabled and one that is not compatible with the version of OpenSSL being used. # that is not TLS/SSL enabled and one that is not compatible with the version of OpenSSL being used.
# The function sets the global ALL_FAILED_SOCKETS. It is mandatory to be set to true unless the user
# wants to do pure openssl based tests.
#
determine_optimal_sockets_params() { determine_optimal_sockets_params() {
local -i ret1=1 ret2=1 ret3=1 local -i ret1=1 ret2=1 ret3=1
local i proto cipher_offered local i proto cipher_offered
@ -22623,7 +22626,8 @@ determine_optimal_sockets_params() {
# This function determines (STARTTLS_)OPTIMAL_PROTO. It is basically a workaround function as under certain # This function determines (STARTTLS_)OPTIMAL_PROTO. It is basically a workaround function as under certain
# circumstances a ClientHello without specifying a protocol will fail. # circumstances a ClientHello without specifying a protocol will fail.
# Circumstances observed so far: 1.) IIS 6 and openssl 1.0.2 as opposed to 1.0.1 2.) starttls + dovecot imap. # Circumstances observed so far: 1.) IIS 6 and openssl 1.0.2 as opposed to 1.0.1 2.) starttls + dovecot imap.
# Independent on the server side it seems reasonable to to know upfront which protocol always works # Independent on the server side it seems reasonable to to know upfront which protocol always works.
# All clientHellos are openssl based here as opposed to determine_optimal_sockets_params() .
# #
# arg1: if empty: no STARTTLS, else: STARTTLS protocol # arg1: if empty: no STARTTLS, else: STARTTLS protocol
# The first try in the loop is empty as we prefer not to specify always a protocol if we can get along w/o it # The first try in the loop is empty as we prefer not to specify always a protocol if we can get along w/o it
@ -22770,13 +22774,13 @@ determine_optimal_proto() {
elif ! "$HAS_SSL3" && [[ "$(has_server_protocol "ssl3")" -eq 0 ]] && [[ "$(has_server_protocol "tls1_3")" -ne 0 ]] && \ elif ! "$HAS_SSL3" && [[ "$(has_server_protocol "ssl3")" -eq 0 ]] && [[ "$(has_server_protocol "tls1_3")" -ne 0 ]] && \
[[ "$(has_server_protocol "tls1_2")" -ne 0 ]] && [[ "$(has_server_protocol "tls1_1")" -ne 0 ]] && [[ "$(has_server_protocol "tls1_2")" -ne 0 ]] && [[ "$(has_server_protocol "tls1_1")" -ne 0 ]] &&
[[ "$(has_server_protocol "tls1")" -ne 0 ]]; then [[ "$(has_server_protocol "tls1")" -ne 0 ]]; then
prln_magenta " $NODE:$PORT appears to support SSLv3 ONLY. You better use --openssl=<path_to_openssl_supporting_SSL_3>" prln_warning " $NODE:$PORT appears to support SSLv3 ONLY. You better use --openssl=<path_to_openssl_supporting_SSL_3>"
fileout "$jsonID" "WARN" "$NODE:$PORT appears to support SSLv3 ONLY, but $OPENSSL does not support SSLv3." fileout "$jsonID" "WARN" "$NODE:$PORT appears to support SSLv3 ONLY, but $OPENSSL does not support SSLv3."
ignore_no_or_lame " Type \"yes\" to proceed and accept all scan problems" "yes" ignore_no_or_lame " Type \"yes\" to proceed and accept all scan problems" "yes"
[[ $? -ne 0 ]] && exit $ERR_CLUELESS [[ $? -ne 0 ]] && exit $ERR_CLUELESS
MAX_OSSL_FAIL=10 MAX_OSSL_FAIL=10
else else
prln_bold " Your OpenSSL cannot connect to $NODEIP:$PORT" prln_warning " Your OpenSSL cannot connect to $NODEIP:$PORT"
fileout "$jsonID" "WARN" "Your OpenSSL cannot connect to $NODEIP:$PORT." fileout "$jsonID" "WARN" "Your OpenSSL cannot connect to $NODEIP:$PORT."
ignore_no_or_lame " The results might look ok but they could be nonsense. Really proceed ? (\"yes\" to continue)" "yes" ignore_no_or_lame " The results might look ok but they could be nonsense. Really proceed ? (\"yes\" to continue)" "yes"
[[ $? -ne 0 ]] && exit $ERR_CLUELESS [[ $? -ne 0 ]] && exit $ERR_CLUELESS
@ -22795,12 +22799,13 @@ determine_optimal_proto() {
ignore_no_or_lame " The results might look ok but they could be nonsense. Really proceed ? (\"yes\" to continue)" "yes" ignore_no_or_lame " The results might look ok but they could be nonsense. Really proceed ? (\"yes\" to continue)" "yes"
[[ $? -ne 0 ]] && exit $ERR_CLUELESS [[ $? -ne 0 ]] && exit $ERR_CLUELESS
elif ! "$all_failed" && "$ALL_FAILED_SOCKETS" && ! "$SSL_NATIVE"; then elif ! "$all_failed" && "$ALL_FAILED_SOCKETS" && ! "$SSL_NATIVE"; then
# For some reason connecting with tls_sockets/sslv2_sockets didn't work, but connecting # Edge case: connecting with tls_sockets/sslv2_sockets didn't work, but connecting with $OPENSSL s_client did.
# with $OPENSSL s_client did. # See #2807
# FIXME: Should we include some sort of "please report" note here? prln_warning "This shouldn't happen (pls report): Testing $NODE:$PORT only succeeded using $OPENSSL."
prln_magenta " Testing with $NODE:$PORT only worked using $OPENSSL." prln_warning "But testssl.sh also needs bash sockets to perform its checks correctly.\n"
prln_magenta " Test results may be somewhat better if the --ssl-native option is used." outln "You can try to continue using the --ssl-native option but the results are likely not complete."
fileout "$jsonID" "WARN" "Testing with $NODE:$PORT only worked using $OPENSSL." outln "Or you can restart using --ssl-native with another openssl version (--openssl <PATH>)."
fileout "$jsonID" "WARN" "Sockets didn't work. Testing NODE:$PORT only succeeded using $OPENSSL."
ignore_no_or_lame " Type \"yes\" to proceed and accept false negatives or positives" "yes" ignore_no_or_lame " Type \"yes\" to proceed and accept false negatives or positives" "yes"
[[ $? -ne 0 ]] && exit $ERR_CLUELESS [[ $? -ne 0 ]] && exit $ERR_CLUELESS
fi fi