This PR enhances support for the latest versions of OpenSSL and LibreSSL.
The development version of OpenSSL at https://github.com/openssl/openssl/ is version 3.0.0-dev. So, checks for OpenSSL versions need to support this version as well. At the same time, the latest versions of LibreSSL are 3.0.0, 3.0.1, and 3.0.2, so version number alone will no longer be sufficient to distinguish between OpenSSL and LibreSSL.
In addition to checks for these new version numbers, this PR addresses a couple of other issues:
- In LibreSSL, the "$OPENSSL ciphers" command will not accept any protocol version other than "-tls1" as a parameter (and even including "-tls1" as an option is described as "deprecated"). So, this PR ensures that "$OPENSSL ciphers" is not passed any protocol version option other than "-tls1" is LibreSSL is being used.
- In OpenSSL 3.0.0-dev, the "$OPENSSL dgst" can no longer be used to compute HMACs, but a new "$OPENSSL mac" function has been created. So, this PR changes hmac() to use "$OPENSSL mac" with OpenSSL 3.0.0-dev.
Note that I have not tested the modified version of sub_session_resumption(). I am just assuming that OpenSSL 3.0.0-dev works the same as OpenSSL 1.1.1 and that all versions of LibreSSL work the same as OpenSSL 1.1.0 and earlier.
When tls_sockets() is used for run_protocols(), for each protocol version the results will indicate whether the server responded to a ClientHello for that protocol version with (1) a ServerHello for that same protocol version, (2) a ServerHello for a different (hopefully lower) protocol version, or (3) a handshake failure.
Currently, however, run_prototest_openssl() does not distinguish between cases in which the server responds with a ServerHello for a different (hopefully lower) protocol version and cases in which the server responds with a handshake failure. This PR changes run_prototest_openssl() so that it distinguishes between these two cases (as long as $OPENSSL supports the protocol version specified in the ServerHello).
Making use of the additional information provided by run_prototest_openssl(), this PR also modifies run_protocols() to check that version negotiation was performed correctly even if $using_sockets is false.
Note that one special case needed to be addressed. If an SSLv3-only server is being tested using an $OPENSSL that does not support SSLv3, then $latest_supported must not be set to SSLv3. In the case of a server like this, it is possible that support for SSLv3 will be determined by determine_optimal_sockets_params(), which will cause run_protocols() to report that the server supports SSLv3, even though $OPENSSL does not support SSLv3 and testing is being performed in --ssl-native mode. If $latest_supported were set, then later tests in run_protocols() would incorrectly report a version negotiation failure, even though the failure to connect was a result of a limitation of $OPENSSL rather than a fault of the server.
When running in debugging mode, HAS_DIG and friends was
still false as check_resolver_bins() was called too late.
This amends basically bac0f66112 .
In cases where a certificate has two CNs, the output contained
a linefeed. This replaces the line feed by a space.
This fixes a bug e.g. when supplying a proxy by a DNS name, testssl couldn't resolve the name as the HAS_ variables initialized by ``check_resolver_bins()`` was done later than ``check_proxy()``.
The patch just puts ``check_resolver_bins()`` earlier in "main"
run_prototest_openssl() currently calls "$OPENSSL s_client" twice, once with $PROXY and once without. The problem is that the results of the first call are just ignored. This commit changes run_prototest_openssl() so that the attempt without $PROXY is only tried if the first attempt was unsuccessful.
If --ssl-native is being used and the server supports SSLv2, but does not support any SSLv2 ciphers, there is a missing line break after the warning message is printed.
run_prototest_openssl() currently checks only stdout for the string "no cipher list", which is an indication that the server supports SSLv2, but no ciphers for that protocol. However, the output that includes "no cipher list" is sent to stderr.
This PR fixes a minor problem with run_protocols() in "--ssl-native" mode if $OPENSSL does not support TLS 1.3. Currently, the warning message that $OPENSSL does not support a protocol is printed when run_prototest_openssl() is called. This causes a problem for the output if $OPENSSL does not support TLS 1.3, since the run_prototest_openssl() is called before the results for TLS 1.2 are printed. The result is something like this:
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 offered (deprecated)
TLS 1.1 offered (deprecated)
Local problem: /home/cooper/Desktop/testssl.sh/bin/openssl.Linux.x86_64 doesn't support "s_client -tls1_3"
TLS 1.2 offered (OK)
TLS 1.3 NPN/SPDY not offered
ALPN/HTTP2 http/1.1 (offered)
When processing a command line for parallel mass testing, create_mass_testing_cmdline() did not account for the newer shortened versions of the output file options: -oj, -oJ, -oC, and -oH. This caused the command line for the child processes to be incorrect.
If a server offers TLS 1.3 only and the cipher order is server side this commit changes the severity level to INFO.
Also it changes nope to no in two places
This commit addresses the comments in #1205. If a server only supports TLS 1.3, then it is not considered an issue if the server does not enforce a cipher order. However, if the server does not support a cipher order for TLS 1.2 and below, then that is an issue, even if the server does support a cipher order for TLS 1.3.
This PR is an attempt to fix#1163 by running separate tests for a server cipher order preference to TLSv1.3 and for SSLv3 - TLSv1.2.
If the server supports TLSv1.3, then a test is performed to determine whether the server enforces a cipher order to TLSv1.3. A separate test is performed for SSLv3 - TLSv1.2 unless it is known that the server does not support any of these protocols.
If the server enforces a cipher order for SSLv3 - TLSv1.2, but not for TLSv1.3, then cipher_pref_check() is not called for TLSv1.3, since cipher_pref_check() is intended to show the cipher order that the server enforces. As TLSv1.3 will be the negotiated protocol if it is supported, the negotiated cipher for TLSv1.3 will already be presented.
This PR still has one major flaw, which may create a problem when testing a TLSv1.3-only server. If run_protocols() is run before run_server_preference(), then everything will be okay, as run_server_preference() will be able to determine that SSLv3 - TLSv1.2 are not supported. However, if run_server_preference() is run by itself, run_server_preference() will not know that SSLv3 - TLSv1.2 are not supported and so it will try to determine whether the server enforces a cipher preference order for these protocols. The attempt to connect to the server will fail, but at the moment run_server_preference() doesn't know whether the failure is because the server does not support SSLv3 - TLSv1.2 or because the server supports at least one of these protocols, but does not support any ciphers in $list_fwd. At the moment, run_server_preference() incorrectly flags an error.
One option would be to perform additional tests against the server in this case to determine the reason for the connection failure. Another option would be to have some code that is always run earlier, such as determine_optimal_proto(), test whether a server that supports TLSv1.3 supports any earlier protocols (SSLv3 - TLSv1.2).
In run_drown(), $jsonID is set to "DROWN" and most calls to fileout() are of the form
fileout "$jsonID" ...
However, one call is written as
fileout "DROWN" ...
This PR changes this one call to be consistent with the others. This does not change the functionality of the program.
At the moment, $do_starttls is initialized to true in initialize_globals() and then it is set to true again in parse_cmd_line() if the --starttls command line option is used. Presumably the intention was to set $do_starttls to false in initialize_globals().
This PR fixes a minor bug in parse_tls_serverhello(). In some cases the server's entire response is not retrieved. In these cases, it is possible that the response from the server ends with a portion of a handshake message.
The loop at the beginning of parse_tls_serverhello() extracts the various handshake and alert messages from the server's response. If it gets to the end of the response, and what is at the end is not a complete message, it should just ignore that fragment and break out of the loop. At the moment, however, parse_tls_serverhello() just continues in the loop rather than breaking out. This has not been a problem up to now, since $msg_len is usually set to a positive value from a previous iteration of the loop, which causes the loop to end.
In the case of the server identified in #1353, however, $msg_len is 0 and so the continue rather than break results in an endless loop.
Add another pattern because the SEDs tested so far do not seem to be fine with header containing x0d x0a (CRLF) -- which is the usual case. So we also trigger on any sign on a single line which is not alphanumeric (plus _)
See #1351
This PR fixes a bug in modify_clienthello() that occurs when client simulation is being performed, the ClientHello contain an SNI extension, and $SNI is empty. In the case, modify_clienthello() should just skip over the SNI extension and not include one in the modified ClientHello. However, the code currently only skips over the 2-byte extension type. The result being that the remainder of the extension is included in the modified ClientHello. This PR fixes the problem by ensuring the $offset is advanced whether or not $SNI is empty.
PR #1336 included logic to pre-test the server side with sockets
and/or with openssl. However when the user supplied --ssl-native
sockets were never tested before. As a result ALL_FAILED_SOCKETS
was still true, so that the final eif statement complaint erroneously
that sockets didn't work but openssl does.
Also Travis complaint.
This PR fixes it by checking SSL_NATIVE to the final part of the
if statement.
One could also test sockets before and then set ALL_FAILED_SOCKETS
appropriately but that would only make sense if the socket methods
like run_robot() or run_heartbleed() would check ALL_FAILED_SOCKETS
first.
At the moment I went for this as it is easier and the case that sockets
aren't working but openssl does seems not very likely.
There are a few places where testssl.sh sends a TLS 1.2 (or TLS 1.3) ClientHello and expects the server to respond with a ServerHello as long as it supports TLS 1.2 (or TLS 1.3) or earlier.
run_protocols() performs a fairly thorough check for a server's ability to handle version negotiation, but the problem may also be caught by determine_optimal_sockets_params(), if the server rejects a TLS 1.2 ClientHello even though it supports some earlier protocol version.
In the future, we could try to make use of $OPTIMAL_SOCKETS_PROTO in order to make testssl.sh work a bit better with servers (if any still exist) that don't handle version negotiation correctly. At the moment, though, this PR just prints a warning to the user that the server is buggy, and that this may lead to problems in the scan. It doesn't call fileout() to add anything to the JSON/CSV output, since run_protocols() should already be doing that.
This PR modifies run_protocols() to use the information collected by determine_optimal_sockets_params(). If it has already been determined that a protocol is supported, then no test is run. run_protocols() will still run a test for a protocol even if it has been determined that the server does not support that protocol. The reason for running the test is to verify that the server handles version negotiation correctly. This could be a TLSv1 server that rejects a TLSv1.2 or TLSv1.3 ClientHello, or it could happen in the opposite direction. At one point there was a server that would respond to an SSLv3 ClientHello with a TLSv1.2 ServerHello.
This PR required a couple of changes to determine_optimal_sockets_params() so that additional information could be passed to run_protocols(). If the server supports TLS 1.3, then run_protocols() needs to know which version (RFC 8446, draft 28, draft 27, etc.) rather than just that TLS 1.3 is supported. If the server supports TLS 1.2, but not TLS 1.3, then run_protocols() needs to know about at least one TLS 1.2 cipher that the server supports so that it can form a TLS 1.3 ClientHello that has no more than 128 ciphers and that should result in the server returning a TLS 1.2 ServerHello.
In a PR that I'm developing to to use the results of determine_optimal_sockets_params() in run_protocols() I add specific versions of TLS 1.3 to PROTOS_OFFERED (e.g., tls1_3_rfc8446, tsl1_3_draft28). If that PR is accepted, then the current check for TLS 1.3-only will no longer work. So, this commit changes the way that the check for TLS 1.3-only is performed in order to avoid problems if the other PR is merged.
This PR takes advantage of the testing done by determine_optimal_sockets_params() in order to simplify determine_sizelimitbug().
By the time that determine_sizelimitbug() is called, determine_optimal_sockets_params() has already determined whether TLSv1.2 ClientHello with 128 ciphers (including 00FF) sent by tls_sockets() works, and it has set TLS12_CIPHER to a list of exactly 128 ciphers (including 00FF) that works with the server. So, determine_sizelimitbug() doesn't have to check whether the server supports TLSv1.2 and no longer needs to send tests using 127 or 128 ciphers. determine_sizelimitbug() can just perform one test with 129 ciphers, if the server supports TLSv1.2, and use the results to set $SERVER_SIZE_LIMIT_BUG.
This PR reverts determine_optimal_proto() to use OpenSSL again rather than tls_sockets().
The primary reason for this is that the primary purpose of determine_optimal_proto() is to set OPTIMAL_PROTO, which is only used with $OPENSSL s_client. So, the best way to determine what works best on the $OPENSSL s_client command line is to use $OPENSSL s_client.
In most cases, determine_optimal_proto_sockets_helper() would set OPTIMAL_PROTO to an acceptable value, but it might not always do so. For example, suppose that a server
* supports different cipher suites with different protocols,
* supports TLSv1.2, but only with cipher suites not supported by $OPENSSL, but
* supports TLSv1.1 with at least one cipher suite supported by $OPENSSL.
In the above case, determine_optimal_proto_sockets_helper() would set OPTIMAL_PROTO to "-tls1_2", but testing using $OPENSSL would result in OPTIMAL_PROTO being set to "-tls1_1".
Using $OPENSSL for determine_optimal_proto() also allows for edge cases to be detected earlier:
* If the server only supports TLSv1.3, and $OPENSSL does not support TLSv1.3, then the code in this PR will detect that (rather than waiting until run_protocols() is executed).
* The code in this PR can also detect if the server only supports SSLv3 (and possibly also SSLv2), but $OPENSSL does not support SSLv3.
* This code can also detect the (rare) case in which connections using $OPENSSL succeed, but connections using tls_sockets() fail.
[Note also that in the current code, if $all_failed is true, then a message may be printed that $OPENSSL is not IPv6 aware, even if testing was performed using tls_sockets() rather than $OPENSSL.]
This PR fixes an issue with sub_session_resumption() when using OpenSSL 1.1.1.
As noted in #1335, some servers will return a session ticket for TLSv1.2, but not for TLSv1.3.
OpenSSL 1.1.1 does not support the "-no_ssl2" option, and so when using OpenSSL 1.1.1 sub_session_resumption() adds $OPTIMAL_PROTO to the $OPENSSL s_client command line. When determine_optimal_proto_sockets_helper() is called, $OPTIMAL_PROTO will generally be set to "-tls1_2" (or "-tls1_1" or "-tls1") unless the server is a TLSv1.3-only server. As a result sub_session_resumption() will specify that same protocol on the command line if OpenSSL 1.1.1 is being used.
If "--ssl-native" is used, however, then determine_optimal_proto() will set $OPTIMAL_PROTO to "-tls1_3" if the server supports TLSv1.3 (and doesn't use STARTTLS). Similarly, if the version of determine_optimal_proto() in #1336 is used, then $OPTIMAL_PROTO will usually be empty. In either case, sub_session_resumption() will send a TLSv1.3 ClientHello, even if the server only supports session tickets for TLSv1.2 and below.
This PR appears to fix the problem. This PR makes no changes when using a version of OpenSSL that supports "-no_ssl2". When using a version of OpenSSL that does not support "-no_ssl2", however, rather than using $OPTIMAL_PROTO, this PR has sub_session_resumption() use whatever protocol version the server connected with when $sessticket_lifetime_hint was set.
There is a problem if a TLSv1.3-only server is tested using the OpenSSL 1.0.2-chacha binary and $OSSL_SHORTCUT is true.
$HAS_NO_SSL2 is set to true when find_openssl_binary() is called with OpenSSL 1.0.2-chacha. /usr/bin/openssl does not have the -no_ssl2 option, but the second call to find_openssl_binary(), after setting $OPENSSL to /usr/bin/openssl, does not set $HAS_NO_SSL2 to false. So, later calls to $OPENSSL s_client include the -no_ssl2 option, resulting in connection failures.
This PR fixes the problem by modifying find_openssl_binary() to ensure that every OpenSSL-dependent variable is set by this function.
This PR fixes two issues with finding session tickets when using OpenSSL 1.1.1.
First, if OpenSSL connects to the server using TLSv1.3 and it receives more than one Post-Handshake New Session Ticket, then the "TLS session ticket lifetime hint" will appear more than once in $TMPFILE. This will cause the line to appear more than once in $sessticket_lifetime_hint, which causes problems when trying to extract the $lifetime and $unit from $sessticket_lifetime_hint.
This PR fixes the first problem by changing the awk expression in the lines that set sessticket_lifetime_hint so that only the first line with "session ticket lifetime" is extracted.
The second issue is that some servers (e.g., google.com) return a session ticket for TLSv1.2, but not for TLSv1.3. For such servers, testssl.sh will miss the session ticket if $OPTIMAL_PROTO is empty or "-tls1_3" and the --ssl-native flag is not set.
This PR addresses the second issue with the changes in lines 9047 - 9053 -- the code that is intended to provide a last chance to find a session ticket.
If $OPENSSL supports TLSv.1.3 and the server returns session tickets for TLSv1.3 connections, then the session ticket would have already been found by get_server_certificate(), since get_server_certificate() uses $OPENSSL for TLSv1.3 if $OPENSSL supports TLSv1.3. So, in such circumstances, the code in liens 9047 - 9053 should not try again with TLSv1.3. So, if $OPENSSL supports TLSv1.3 and $OPTIMAL_PROTO is empty or is set to "-tls1_3" (either of which would result in a TLSv1.3 ClientHello), the "$OPENSSL s_client" call is changed to specify -no_tls1_3 rather than $OPTIMAL_PROTO.
The code on line 9047 is also changed to only make this final try is $TLS13_ONLY is false. If $TLS13_ONLY is true, then either:
* $OPENSSL does not support TLSv1.3 and the connection attempt would fail anyway; or
* $OPENSSL supports TLSv1.3, in which case any session ticket would have been found by get_server_certificate(), since get_server_certificate() uses $OPENSSL for TLSv1.3 if $OPENSSL supports TLSv1.3.
In either case, there is no reason to try again to find a session ticket.
This commit adds some more checks to determine_optimal_sockets_params(). These additional checks will almost never need to be run, and so will not slow down the typical run of testssl.sh, but adding them will provide information that can be useful for other parts of testssl.sh.
These additional checks will only be run if the server does not support TLSv1.3 and a TLSv1.2 ClientHello is not successful. This means that either:
* The server is not an TLS/SSL enabled server.
* The server only supports SSLv2.
* The server supports some protocol in SSLv3 - TLSv1.1, but does not handle version negotiation correctly.
Adding these additional checks helps in at least the following ways.
If determine_optimal_proto() (assuming it is reverted to using OpenSSL) is unable to connect to the server using OpenSSL, it will be possible determine whether the problem is the the server does not support TLS/SSL or that a different version of OpenSSL is needed to test the server.
If the code in #1205 for run_server_preference() is unable to connect when checking for a cipher order, the reason for the failure will be known, making it possible to determine the correct response to the failure.
This PR adds a new helper function that is run just prior to determine_optimal_proto() and that determines the what information tls_sockets() should include in a ClientHello.
For a TLSv1.3 ClientHello, determine_optimal_sockets_params() determines whether tls_sockets() should use 0x33 or 0x28 are the extension number for the key_share extension. 0x33 should be used with servers that support RFC 8446 or drafts 23-28. 0x28 should be used with servers that support drafts 18-22.
For a TLSv1.2 ClientHello, determine_optimal_sockets_params() determines what cipher list tls_sockets() should send. For most servers, the list of ciphers in $TLS12_CIPHER works best. But, there are some servers that do not support any ciphers in $TLS12_CIPHER, but do support one or more ciphers in $TLS12_CIPHER_2ND_TRY.
This PR fixes a few issues with run_protocol():
* In the case that the call to `tls_sockets "03" "$TLS12_CIPHER"` had a return value of 2, the code determining what results to print was looking at `$DETECTED_TLS_VERSION`. However, the value of this variable was set by the later call to `tls_sockets "04" "$tls13_ciphers_to_test"`. This caused incorrect results in the case of a server that supports TLSv1.3 and TLS1.1 (or earlier), but not TLSv1.2. This PR saves the value of `$DETECTED_TLS_VERSION` in `$tls12_detected_version` and then uses this variable later rather than `$DETECTED_TLS_VERSION`.
* When running in debug mode with a server that does not support TLSv1.3, testssl.sh was printing
TLS 1.3 -- downgradednot offered and downgraded to a weaker protocol"
This PR fixes the output by not printing the "--downgraded"
* As noted in #1329, run_protocols() was treating a downgrade from TLSv1.2 as less bad if the server supports TLSv1.3. This PR changes this code back to treat any downgrade from TLSv1.2 as equally bad.
* In order to be consistent with the TLSv1.3 test, this PR changes the TLS1.2 test output to say "not offered and downgraded to a weaker protocol" if a TLSv1.2 ClientHello results in a downgraded connection.
This PR fixes a problem in run_protocols() that was introduced by 7ec3c6ab99.
7ec3c6ab99 changes run_protocols() to perform the initial testing for TLSv1.3 support before testing for TLSv1.2 support. The problem with this is that the code for testing TLSv1.3 makes use of the results of the TLSv1.2 testing.
In the current code, Line 5183 looks at the value of $subret to determine whether the TLSv1.2 ClientHello resulted in a successful connection. However, $subet has not yet been set (it has just been initialized to 0 at the beginning of the function). Since $subret will always be 0, the code will try to extract a cipher from $TEMPDIR/$NODEIP.parse_tls_serverhello.txt. This may work, since $TEMPDIR/$NODEIP.parse_tls_serverhello.txt may have been populated by a prior function call, but this is not how the code was intended to work.
This PR fixes the problem by doing the TLSv1.2 testing before the TLSv1.3 testing is done. It still waits until both have been tested, however, before outputting the results, so that the output for TLSv1.2 can be modified depending on whether TLSv1.3 is supported.
In order to not repeatedly call check_resolver_bins() the function
was moved to top level. As each check in check_resolver_bins now
is only executed once, it should also work faster. Each get_*_record()
now uses HAS_ variables only.
Also check_resolver_bins() contain now the check whether
idn/idn2 support is available.
Then the IDN URI conversion snipplet was moved to the final function
parse_hn_port() which does operations in the URI supplied.
This PR adds a few quotes to some arguments which when previous code
was executed properly weren't needed.
Also it improves the IDN code from @teward, so that when idn2 is
available, a conversion will be tried, and when idn is available
and/or idn2 failed, a conversion will be tried.
Finally it'll be tried to continue without conversion, hoping that
the DNS client binaries can cope with the IDN URI.
This is not good enough yet and needs to be complemented, see discussion
@ #1321.
The Finding of other_headers such as "Referrer-Policy" during file output are displayed as `$header: $HEADERVALUE` instead of only `$HEADERVALUE` as the good_headers. This leads to duplicate information e.g. in the JSON output file.
... and thus this commit addresses #916.
It does that via a (quite) pre-test which checks for a general availabilty
of TLS 1.3 before the TLS 1.2 protocol test is being run and decides
based on that how a missing TLS 1.2 will be echoed.
Later on the complete TLS 1.3 test will be continued using the results
from the TLS 1.3 pre-test.
This commit addresses #1251 and gives a slight warning when still
using those protocols as government standards are or are at least
to expect also to deprecate those protocols. PCI DSS requires not
to use TLS 1.0 anymore and browser vendors supposedly will deprecate
TLS 1.0/1.1 next year.
This is a WIP for testing. It was committed already in May
(22ad490ea7b2868a4fd45862ca0bf8a3d8f24ea6) but somehow it was
lost.
Comments would be appeciated.
Open:
- how to treat non-HTTP protocols
- TLS 1.3 only hosts will mark the absence of TLS 1.2 as
a medium finding
In cases where TLS 1.3 is the only protocol supported by the server (as e.g.
in #1312), testssl.sh has some limits with the supplied binary.
For now (3.0) there's no perfect technical solution. This PR however improves
the verbosity what's going on and recommends to use an openssl binary
supporting TLS 1.3. And if the "secret" variable OSSL_SHORTCUT is set to true,
it automatically chooses that if available (it's a hack to do so and not
recommended. I just did it as a PoC).
In the next development we should consider probing this upfront!
Furthermore this PR removes some unnecessary quotes in double square brackets.
This commit proactively tries to address cases where the server side
adds Null Bytes after or during ClientHello in cases where it should be text only.
Now VAR2=$(< $VAR1) is being replaced by VAR2=$(cat -v $VAR1) which is normally
not best practice and also considered a useless use of "cat", see
https://web.archive.org/web/20160711205930/http://porkmail.org/era/unix/award.html#uucaletter.
Especially with bash 3.2 (Mac OS X) AND when on the server side binary chars it
was reported to not work ok, see #1292.
Performance measurements showed no to barely measureable penalty (at max 1s displayed difference
in 9 tries).
Travis updated the container images so that the perl
reference to 5.18 was outdated. We use now 5.26 which
works, however we should consider to be more flexible.
JSON::Validator didn't compile in the container. Thus
we switched to just use 'JSON'. That also supports JSON
pretty. For the future we should just test for valid JSON
in all unit test files as it is more effective.
For some reason CVE-2009-3555 ended up in Secure Renegotiation,
whereas CVE-2009-3555 is in fact the Insecure Client-Side Renegotiation
vulnerability with the MiTM problem <= OpenSSl 0.9.8k.
This fixes that (see also #1086 and #933, #907) by removing the CVE #
from the output. Also tyhe output was changed for Secure Renegotiation
into supported/not vulnerable vs. Not supported / VULNERABLE
Some comments were added.
As noted in #1249 STARTTLS with sockets doesn't
work.
This commit fixes that by correcting the STARTTLS
handshake for postgresql. It has to be send via
sockets instead of echo. The server side then will
respond with "S" when STARTTLS is supported. For this
starttls_io() was slightly modified so that also
an input (from the server perspective) is not necessary.
It's fast too
As noted in #1288 with some terminal settings under Linux there
appeared some ~garbage on the screen.
This fixes that by partly reverting 695d02157a .
At least now and under an older OpenBSD like 6.2 this doesn't seem
to be necessary.
CERT_COMPRESSION was declared always with fast in ... so that the variable
was always false. This PR fixes that. In addition a informational line
that the new TLS extension has been added (if $DEBUG >3).
Also determine_optimal_proto() is not being run if devel mode
($do_tls_sockets) is enabled.
Furthermore as David added HAS_ZLIB as a global run_crime() now makes
use of it too.
This PR addresses #316 and #1280: it implements server name indication
also for STARTTLS which has been supported by a number of server
implemantations, in the meantime.
Also it does a final polish to David's pwnedkeys PR #1274 a while back:
UI improvement and detection of network problems.
In addition to PR #1279 it introduces a env variable to devel
mode so that "CERT_COMPRESSION=true ./testssl.sh --devel <params> <target>"
can be used to explore certificate compression on a host.
draft-ietf-tls-certificate-compression specifies a new TLS extension that allows a client to indicate support for receiving the server's certificates in compressed form. This PR adds initial support for that extension to testssl.sh. It was developed based on an announcement that facebook.com has implemented support for the extension.
This PR does not add a test for a server's support for the new extension, it just adds code to parse_tls_serverhello() that will parse a compressed certificate message if one is present in the server's response. So, in practice, the code in this PR will not actually be used until additional code has been added that sends a ClientHello with the compress_certificate extension.
The code in this PR can be tested by using the --devel option and by changing line 19347 from
tls_sockets "$TLS_LOW_BYTE" "$HEX_CIPHER" "ephemeralkey"
to
tls_sockets "$TLS_LOW_BYTE" "$HEX_CIPHER" "all+" "00,1b, 00,03, 02, 00,01"
testssl.sh can then be called using
testssl.sh --debug 3 --devel 04 "13,01" facebook.com
Note that this PR adds a test for zlib support to find_openssl_binary(). The test uses $OPENSSL zlib in the same way it is used in parse_tls_serverhello(). The test asks $OPENSSL zlib to uncompress the compressed version of the string "zlib" and the checks to see whether the decompression was performed correctly. There is already a test for zlib support in run_crime(), but I did not check to see whether the check in run_crime() could be replaced with a check of the new $HAS_ZLIB variable.
A couple of checks required sockets but e.g. LDAP via STARTTLS
throwed an error (FIXME: LDAP+STARTTLS over sockets not supported yet)
in fd_sockets().
This adds a temporary workaround so that those functions are bypassed
and LDAP via STARTTLS can be used again.
See also #1258
... which led to a false output in OpenSSL based handshake simulations.
secp256r1 is prime256v1
secp192r1 is prime192v1
Also a few varaiables were added in debug output (environment.txt)
This PR changes run_protocols() so that, when using tls_sockets(), support for TLSv1.3 is only marked as pr_svrty_best() if the final (RFC 8446) version is supported. It also changed run_protocols() so that support for TLSv1.3 is marked as pr_svrty_best() if OpenSSL is used (i.e., if the --ssl-native option is specified).
One potential issue is that the --ssl-native version assumes that if OpenSSL supports TLSv1.3 it supports the final (RFC 8446) version of the protocol. If the tester is using a development version of OpenSSL 1.1.1 rather than the final version, then the protocol test will actually be indicating whether the server supports the same draft version of OpenSSL as the $OPENSSL being used to perform the tests.
Currently the -outfile, -oa, -outFile, and -oA assume that <fname> being provided is to be used as a filename, unless it is "auto." However, all of the individual options (e.g., --logfile) allow for a directory name to be provided instead of a file name.
This PR changes the handling of the -outfile, -oa, -outFile, and -oA options so that if a directory name is provided, the files are created in that directory.
This PR fixes#1243 by modifying create_mass_testing_cmdline() to handle the --outfile, -oa, --outFile, and -oA options in the case that the filename provided is not "auto." It also modifies create_mass_testing_cmdline() so that in the case of serial testing -oj and -oJ are treated the same as --jsonfile and --jsonfile-pretty, respectively.
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.
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.
This commit fixes a the regression "Session Ticket RFC 5077 hint missing/incomplete" #1218.
Reason was that in some case where the ticket lifetime hint was not restrieved before, later
$OPENSSL s_client -connect with -cipher ALL:COMPLEMENTOFALL didn't get the ticket either.
Just using "$OPTIMAL_PROTO" instead of -cipher ALL:COMPLEMENTOFALL fixed it in the cases
tested so far.
Then a global variable is instroduced -- TLS_TICKETS. Which keeps in any case the
state whether session tickets are supported. This is being used to fix#1089. It
remains a bit unclear what is meant in https://tools.ietf.org/html/rfc5077#section-5.6
by "TLS clients MAY be given a hint of the lifetime of the ticket". We use this information
to chck for resumption by ticket which seems realistically the best solution.
Sessin resumption was also made a bit more reliably: The ServerHello is now
being tested for "New" also. If this and "Reused" wasn't detected, an error
is raised.
In general we could do better in keeping and reusing information of a ServerHello
in TMPDIR.
There is currently a bug in determine_optimal_proto_sockets_helper(). In two places there is code of the form:
tls_sockets ...
if [[ $? -eq 0 ]]; then
...
elif [[ $? -eq 2 ]]; then
...
fi
This code does not work as intended since the second check ("elif [[ $? -eq 2 ]]") is actually comparing the results of the first check to 2 rather than the results of the call to tls_sockets().
This PR fixes that problem and also speeds up the code. Since tls_sockets() sets $DETECTED_TLS_VERSION to the protocol version that was negotiated, there is no need to scan $TEMPDIR/$NODEIP.parse_tls_serverhello.txt for this information.
* changed = to ==
* fixed emphasize errors in emphasize_stuff_in_headers()
* add new debian version
* prospectively add Alt-Svc header, see #1209 (won't show up in output yet)
In order to handle better Cisco ACE loadbalancers (almost extinct species) which
have a problem with ClientHellos >127 ciphers we have had introduced a variable which
needs to be filled better with some sense.
This commit does that by introducing the function determine_sizelimitbug() which
is called in lets_roll().
It also removes then redundant code in cipher_pref_check().
Open:
* handle run_grease()
* do we want this information at least in a logfile
* or maybe eben on screen?
See also #1202 .
For non-EC public key algorithm of the server certificate
the terminal output contained the algorithm but not the
file out put. This PR fixes that, see also #1187 and puts
the public key algorithm first in the cert_keySize -- also
for EC cerificates.
In addition it fixes the recognition of ECDSA certificates
which were detected as DSA certificates (order in case
statement).
Also there were in a few double sqaure brackets an assignment operator
'=' instead of a test operator '=='
There were a few, mostly less common ciphers in this check missing.
This commit adds them and fixes#208.
It also removes redundant quotes in double square brackets and
updates documentation for determine_optimal_proto().
This is the last fix for #1087.
It determines STARTTLS_OPTIMAL_PROTO (unless --ssl-native is being used) with
sockets per default which removes cases where an openssl s_client
connect using STARTTLS failed with the initial message 'doesn't seem to be a TLS/SSL
enabled server' and prompt 'Really proceed ? ("yes" to continue)' now shouldn't
happen in those cases anymore.
To not have redundant code determine_optimal_proto_sockets_helper() is being
used for not STARTTLS and plain TLS/SSL.
In addition it looked like this determine_optimal_proto() was not always called in
the beginning when a STARTTLS scan was requested. Instead determine_service()
contained an openssl s_client connect called which was the wrong place and thus
removed. Also now determine_optimal_proto() also for STARTTLS will always being called.
The information on 64 Block ciphers using SSLv2 in the SWEET32
paper is sparse. Maybe becuase SSLv2 is the bigger problem.
For completeness also SSLv2 ciphers were added to the SWEET32 check.
It fixes finally #613.
Also with --ssl-native when no ciphers or only a handlful of ciphers
are supplied by openssl there's a "Local problem" warning issued and
the test aborted as the results would make much sense otherwise.
A few peices of documenation of parameters and return conditions
for sslv2_sockets() and has_server_protocol() was added.
This is a minor bug when performing run_server_preference() if the server cannot handle ClientHello messages with more than 128 ciphers (i.e., $SERVER_SIZE_LIMIT_BUG is true) and the server supports at least one cipher in 'CAMELLIA:IDEA:KRB5:PSK:SRP:aNULL:eNULL'.
The problem is that `$OPENSSL s_client` is called with a cipher list such as
ECDHE-RSA-AES256-GCM-SHA384:CAMELLIA256-SHA:AES256-SHA256
then
ECDHE-RSA-AES256-GCM-SHA384:CAMELLIA256-SHA:AES256-SHA256:-CAMELLIA256-SHA
then
ECDHE-RSA-AES256-GCM-SHA384:CAMELLIA256-SHA:AES256-SHA256:-CAMELLIA256-SHA:-AES256-SHA256
and finally
ECDHE-RSA-AES256-GCM-SHA384:CAMELLIA256-SHA:AES256-SHA256:-CAMELLIA256-SHA:-AES256-SHA256:-ECDHE-RSA-AES256-GCM-SHA384
The last call to $OPENSSL s_client produces an error since the list of ciphers to send is empty, and this results in connectivity_problem() being called to print a "openssl s_client connect problem" warning.
This PR fixes the problem by constructing a list of ciphers to test for and by not calling $OPENSSL s_client if the list is empty.
As Dirk commented in #1199, TLS_GOSTR341094_RSA_WITH_28147_CNT_MD5 uses an RSA certificate, not a GOST certificate. So, this PR moves that cipher suite (0xff, 0x00) from the GOST list to the RSA list.
According to etc/cipher-mapping.txt, TLS_GOSTR341094_RSA_WITH_28147_CNT_MD5 uses RSA for both authentication and key exchange, so this PR places it on the list of cipher suites that uses RSA for encryption rather than signatures.
With OpenSSL 1.1.0 (and maybe other versions), the `ciphers` function lists many cipher suites that are not actually supported by the `s_client` option. This PR fixes that by using the `-s` option whenever `$OPENSSL ciphers` is used to obtain a list of cipher suites supported by OpenSSL. According to https://www.openssl.org/docs/manmaster/man1/ciphers.html:
```
-s
Only list supported ciphers: those consistent with the security level, and minimum and
maximum protocol version. This is closer to the actual cipher list an application will
support.
```
When the `-s` option is used along with `-tls1`, OpenSSL 1.1.0 will not list any ciphers that only work with TLSv1.2. So, `prepare_debug()` needed to be changed to correctly populate `ossl_supported_tls`, which is supposed to be a list of all non-SSLv2 ciphers supported by the server.
LibreSSL issues an "unknown option" error if the `-s` option is provided, so the `-s` option is only included in the command line if `$OPENSSL` has been determined to support it.
This PR is needed so that `prepare_debug()` can correctly determine which cipher suites are or are not supported by `$OPENSSL`.
This PR removes an extra call to `$OPENSSL s_client` in `get_server_certificates()` and it also changes `get_server_certificates()` to not collect extensions when SNI is not being provided.
This PR modifies get_server_certificate() to use tls_sockets() rather than $OPENSSL for finding certificates using SSLv3 - TLSv1.2, unless $SSL_NATIVE is true. Using tls_sockets() allows testssl.sh to find certificates used by the server even if the server is only using cipher suites not supported by $OPENSSL. This may happen, for example, if the server only supports TLS_ECDHE_ cipher suites with curve X25519 and a version of OpenSSL prior to 1.1.0 is being used. A less likely possibility would be if the server had a certificate with a DH key, and a newer version of OpenSSL that does not support TLS_DH_ cipher suites is being used.
Since tls_sockets() cannot be used to obtain session tickets from the server, an additional test for session ticket lifetime needed to be added.
In order to reduce the number of times the server needs to be queried for certificates, this PR bundles the testing in a similar way to what is already done to test for cipher suites. Currently, each call to get_server_certificate() only tests for one type of certificate. This PR has each call test for more than one type of certificate. For example, one call is made to test for ECDSA, ECDH, DH, DSA, and GOST certificates. If the test is unsuccessful, then the server has none of these certificates. If the test finds a certificate (e.g., an ECDSA) certificate, then another test is run looking for the remaining types (ECDH, DH, DSA, and GOST) until a test is unsuccessful.
For most servers, this will reduce the number of calls to get_server_certificate() from 8 or 9 to 4 or 6.
This fixes#1157.
* Move IDEA to the same category as 3DES
* Rename the category to 3DES_IDEA (JSON)
* Rename 128 Bit category to AVERAGE (JSON)
* Move 256 Bit CBC ciphers into this category too
* Remove category HIGH
Furthermore:
* Code readability improvements, especially in run_cipherlists()
* fix minor bugs (e.g. aNULL ciphers were used in higher categories when --ssl-native was supplied)
* rearrange order for sub_cipherlists()
* proper documentation for arguments of sub_cipherlists() in run_cipherlists()
* add "$cve" "$cwe" arguments to fileout in sub_cipherlists() -- (was passed before but not used)
* change debugging leftover filenames for sub_cipherlists to the JSON identifier
This PR makes a few improvements to run_server_defaults() when run on an SSLv2-only server.
First, it uses sslv2_sockets() to test the server rather than $OPENSSL, so that it will work even if $OPENSSL does not support SSLv2.
Second, it changes run_server_defaults() to only call get_server_certificate() once if $OPTIMAL_PROTO is -ssl2, since calling more than once is a waste - SSLv2 only supports ciphers that use RSA key exchange.
Finally, as some code assumes that $TEMPDIR/intermediatecerts.pem will exist, even if it is empty, this PR changes a couple of places that delete $TEMPDIR/intermediatecerts.pem to instead make the file empty.
When run_server_preference() is run on a server that only supports SSLv2 it incorrectly reports that the server has a cipher order. The reason for this is that $list_fwd and $list_reverse only include one SSLv2 cipher.
In SSLv2 the server sends a list of all ciphers it supports in common with the client and the client chooses which cipher to use. As a result, the server cannot enforce a cipher order for SSLv2.
So, this PR fixes the problem in run_server_preference() by skipping the test for whether the server enforces a cipher order if $OPTIMAL_PROTO is -ssl2 and simply declares that the server does not enforce a cipher order.
Note that this PR is somewhat dependent on #1194, as #1194 needs to be applied in order for $OPTIMAL_PROTO to be set to -ssl2 when testing an SSLv2-only server.
This PR reorganizes run_cipher_per_proto(). Currently run_cipher_per_proto() runs a for loop, which loops over each protocol and prints the set of supported ciphers for each protocol. This PR simply places the body of the for loop in a separate function from the loop itself. This allows the body of the loop to be called for just a single protocol.
While this PR does not change the way that testssl.sh functions, it would allow for a future change in which run_server_preferences() called cipher_pref_check() for protocols in which the server enforces a cipher order and calls ciphers_by_strength() for protocols in which the server does not enforce a cipher order.
This PR reorganizes cipher_pref_check(). Currently, cipher_pref_check() runs a for loop, which loops over each protocol and prints the set of supported ciphers for each protocol. This PR simply places the body of the for loop in a separate function from the loop itself. This allows cipher_pref_check() to be called for just a single protocol rather than for all protocols. Another PR will make a similar change to run_cipher_per_proto().
The reason for this change is that cipher_pref_check() was only intended to be used in cases in which the server enforces a cipher preference order. Some servers, however, enforce an order for some protocols, but not for others. The change in this PR will make it possible in the future to call cipher_pref_check() only for protocols in which the server enforces a cipher order.
This PR fixes two bugs in determine_optimal_proto().
First, sslv2_sockets() returns 3 if the connection was successful.
Second, if all connection attempts using tls_sockets() were unsuccessful, it is possible that $TEMPDIR/$NODEIP.parse_tls_serverhello.txt will not exist, so copying it or grepping it will lead to an error. Checking that $proto is not 22 will fix this as $proto will be empty is $OPENSSL s_client was used and it will be 00, 01, 02, 03, or 04 if tls_sockets() was used and the connection was successful with some protocol higher than SSLv2.
This PR fixes a bug in get_cipher() - one that also appears in sclient_connect_successful().
The code currently assumes that cipher names contain only uppercase letters and numbers. However, ciphers that do not provide authentication include "anon" in the name, which is written in lowercase.
This PR fixes the problem by allowing lowercase letters to appear in cipher names (except in the first portion of the name).
Note that no change was made to similar code in get_protocol(), since the line in get_protocol() only matches TLSv1.3 ciphers, which do not contain any lowercase letters.
In case where the OpenSSL version used cannot successfully do openssl s_client
connects there are a few problems, see #1087.
This PR partly addresses them by
* changing the logic of HTTP header failure: we don't terminate anymore but
continue with a warning message
* we try to find out what the reason was: If it is a missing curve we signal
it back to the user
* we keep track in a global variable KNOWN_OSSL_PROB. It's not being used yet
on all connects as it has not been decided whether we do a connect despite
we know if there's a problem or rather not.
* Give hints to the user for resumption tests, secure renegotiation, CRIME and BREACH.
For the latter --assume-http needs to be supplied for any output.
Also: for finding the OPTIMAL_PROTO now (unless --ssl-native is being used)
sockets are the default which removes in cases where an openssl s_client
connect fails, the initial message 'doesn't seem to be a TLS/SSL enabled server'
and prompt 'Really proceed ? ("yes" to continue)'. For STARTTLS this needs
to be done as well.
Here a minor bug was fixed: when openssl s_client connect in determine_optimal_proto()
succeeded without a protocol supplied, OPTIMAL_PROTO wasn't set. A statement was
added but now it is only being used when --ssl-native was supplied.
Leftover for this workaround is to find out why the number of certificate retrieved is
zero in those cases, despite the fact that there's a valid 'host_certificate.pem' from
tls_socket() calls. Thus still run_server_defaults() stops after 'TLS clock skew'
as certificate_info() is not being called in run_server_defaults(). For now in
those cases 'Problem: Host certificate found but we can't continue with "server defaults"'
is being printed.
In general for the future it would be great if we could e.g. retrieve the header over
TLS sockets.
This PR fixes two problems with modify_clienthello().
First, the function was incorrectly using the variable $key_share instead of $new_key_share. Since $key_share is defined when modify_clienthello() is called from resend_if_hello_retry_request(), but not when it is called from client_simulation_sockets(), this bug does not seem to result in incorrect behavior, but it should still be fixed.
Second, when this function is used to create a second ClientHello in response to a HelloRetryRequest, it removes the key_share extension from the original ClientHello and then appends the new key_share extension at the end. According to https://mailarchive.ietf.org/arch/msg/tls/8ZKCyamcYFaV90h6nf4MUnSPkEE, however, extensions must appear in the second ClientHello in the same order in which they appeared in the first ClientHello.
I am not aware of any servers that will actually complain if the extensions in the second ClientHello do not appear in the same order as in the first ClientHello, bug this fix helps to ensure that the ClientHello messages testssl.sh sends are in compliance with the standard.
This PR is an attempt at addressing #1185. According to https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf, if eTLS is in use, then the certificate should contain a subjectAltName extension with one or more "names" containing "visibility information." The "visibility information" is encoded as an otherName with a type-id of 0.4.0.3523.3.1 and a value of
VisibilityInformation ::= SEQUENCE {
fingerprint OCTET STRING (SIZE(10)),
accessDescription UTF8String }
The etsi_etls_visibility_info() function determines whether the certificate includes an "visibility information," and, if it does, extracts the fingerprints and access descriptions.
This PR is a work-in-progress for two reasons. First, it has not been tested against any real certificates that contain "visibility information." Testing against real certificates would be helpful to verify that the parsing of the certificate is correct.
Second, the presentation of the visibility information (both in the printed text and in what is sent to fileout()) may need improvement. Having seen no examples, it is not clear what the contents of accessDescription can be expected to look like. The document says that the contents will be "human-readable text," but it is not clear whether the description will be relatively short or very long.
To finalize #1157 following was done
* move 3DES one line above
* put 128 bit CBC ciphers (ARIA, Camellie and AES) SEED and IDEA into 128Bit
* the remaining 256 bit ciphers NOT supporting AEAD Mac into high
Also 128 bit ciphers are getting a small complaint (LOW, yellow) if
available instead of red (for SEED and IDEA before)
To ease the (future) output rated_output() is included, but it's not being used
yet.
Also often I have docker hosts for testing. If I use them while the external
network is down, I still experience DNS timeouts. I added for dig
timeout values which proved to be reasonable in my tests with and
without network.
Also if an IPv4 or an IPv6 address was supplied testssl.sh doesn't
do (futile) DNS lookups anymore.
... to enable checks whether a curve has been detected by sockets
won't be detected and/or makes problems with remaining openssl
s_client + other calls
Related to #1087
This PR addresses the problem (#1037) that if a hostname resolves to multiple IP
addresses only the first one is being scanned as this IP isn't reachable and the
scan terminated here and didn't continue with the 2nd, 3rd etc.
Same applied to scans with --mx.
This based on the global MULTIPLE_CHECKS which is set to true whenever
such a scan is started.
One minor point: Also if the last IP isn't reachable the output will say
"proceeding with next:". I guess that should be clear looking at the (different outputs).
This PR also fixes a scan problem with a single cipher/pattern (-x/--single-cipher):
previously where only one IP was scanned.
Furthermore some redundant quotes were removed.
This commit addresses #934. It adds a line in the log/csv output
and a json object named "scanProblem" when either the function
fatal() is being called and it logs the reason of the fatal error.
As noted in #1157 the logic of different cipher suites put to categories
needed an improvement.
This commit addresses it by moving first RC2 and RC4 cipher suites to
the low category.
More to follow.
This commit fixes#1163 which lead to the misleading output when
a TLS 1.3 enabled server had no preferences for the TLS 1.3 ciphers
but for anything below (like currently for testssl.NET).
The TLS 1.3 handshake in sockets plus the following openssl handshake
was moved to the top in run_server_preference() so that it can be better
determined whether TLS 1.3 is available. If this section's outcome is
TLS 1.3 is negotiated a single TLS 1.3 handshake with 5 ciphers only is
done forward and reverse. The resulting ciphers are later on compared
whether there's a cipher order for TLS 1.3.
Basically this section should be redone, so that all openssl handshakes
are replaced by sockets. As this would consume more time as it appears
reasonable at this point of time, this was not done yet. A starting point
for this would be tls13_list_fwd + reverse. After release of 3.0 90%
of the code will be replaced anyway.
DHE-RSA-SEED-SHA and SEED-SHA was added to the reverse and forward lists
as some old openssl versions + apache use it.
Also:
Googles ALPN_PROTO grpc-exp was added (to be reconsidered at some certain point)
Some redundant quotes in double square brackets were removed.
All "do_*" variables are now in quotes when tested w if or [[
This addresses #1169: When using JSON as output format when mass testing
AND we have a non-fatal condition when e.g. openssl lacks support for
something it led to an invalid JSON as the warning was put into file w/o
a trailing comma.
The commit removes the warning to be put into the output. We still have the
message on screen + in HTML which is not as optimal as it could be.
Also I did some cleanups related to redundant double quotes I stumbled over while
fixing this.
As a kind of a pre-warning this commit allows the n-1 connection problem to
give feedback on the screen (that wasn't working before).
Also the message on the screen is now more clear and the manpage
gives better advice.
Related to #1172
This PR fixes#1165 by changing resend_if_hello_retry_request() to modify the initial ClientHello rather than having it call prepare_tls_clienthello() to try to generate a new ClientHello that is almost the same as the first. The modification is done using a revised version of create_client_simulation_tls_clienthello(), which is now renamed as modify_clienthello().
Since prepare_tls_clienthello() is no longer used to create a second ClientHello message, argument 7 to that function is no longer needed.
There is at least one extension that will fail on a TLSv1.3 ClientHello if the psk_key_exchange_modes extension is not present (see #990). The PR adds the extension to TLSv1.3 ClientHello messages. OpenSSL, Firefox, and Chrome all include this extension in their ClientHello messages, so including it is unlikely to cause problems for any servers.
.. after some discussion. As TLS 1.3 is not tested here
any RFC 7919 primes using this protocol will not show
up (they in in run_pfs() though). To avoid misunderstandings
" DH key detected with <= TLS 1.2" is now being printed.
This PR provides an additional fix for the issue raised by #1159. It defines a third option for the degree of processing that should be performed by tls_sockets(): "all+". When "all+" is provided, the processing is exactly the same as for "all" with the exception of the creation of the supported_groups extension. For a TLSv1.3 ClientHello, curves that are not supported by $OPENSSL are omitted from the supported_groups extension rather than offering these curves as the least preferred option.
The "all+" option is used in run_server_defaults() where, unlike with almost every other call to tls_sockets(), a successful connection is of no use unless the response can be decrypted. This is also the case for run_alpn(), and so the call to tls_sockets() was also changed to "all+" there. But, the change has no effect at the moment, since run_alpn() sends a TLSv1.2 ClientHello.
As a result of #276, `run_server_defaults()` makes several attempts to find certificates that a server offers if the ClientHello is for TLSv1.2 and no SNI is offered. However, these tests are unnecessary if it is already known that the server does not support TLSv1.1.
This PR modifies `run_server_defaults()` so that the the TLSv1.1-only tests are skipped if the server is known to not support TLSv1.1.
This PR fixes#1159. If tls_sockets() connects to a server using TLSv1.3, it cannot be assumed that the server's certificate is available, as testssl.sh may not have been able to decrypt the server's response. This can happen, for example, if X25519 was used for the key exchange and `$OPENSSL` does not support X25519.
If the connection was successful, but the certificate could not be obtained, then this PR tries again using `$OPENSSL`. However, since `$OPENSSL` does not support TLSv1.3, this will only work if the server supports TLSv1.2 or earlier.
This commit addresses #179 and implements NNTP via STARTTLS. I did
a few tests and it did work so far.
However the binary support needs to be done. I backported in my
fork of @PeterMosmans tree the section from OpenSSL 1.1.1 -- but
it didn't work, see https://github.com/openssl/openssl/issues/7722.
I just tried to patch it as I suggested and it worked then. My
patch is pushed soon after to https://github.com/drwetter/openssl-1.0.2.bad,
however I'll better wait for the official OPenSSL 1.1.1 patch.
This commit finalizes #1139. It displays the DH groups
in both run_logjam() and run_pfs() in a simlilar manner
(except the FFDHE groups).
A common small function pr_dh() was introduced which prints
out the dh group and in round brackets colored DH bits.
This commit finally fixes#547 and makes XMPP handshakes at least
as fast as the other STARTTLS handshakes.
It utilizes dd to read from the file descriptor. In all tests
I ran so far it didn't cause any problems. There's a potential
problem though that dd might block.
This PR fixes#924 and does some foundation for #547. It's a
somewhat preliminary push of code and further work for #547 is required.
XMPP is now similar programmed as other STARTTLS handshakes with the exception
that it is not line based but stream based. That is still the catch here and
needs to be addressed: STARTTLS protocols like IMAP + SMTP use
starttls_full_read() which reads lines until the line is completely received or
the timeout was encountered.
The new function ``starttls_io()`` however does a wait (fixed value: 1 second)
as there's no lf or terminator.
The XMPP STARTTLS handshakes are now the same as in OpenSSL.
There are redundant functions in this code which will be removed later.
Also at some places a hint for lmtp was missing which was added.
The cipher suites names in the RFCs stem (mostly) from IANA, see
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
This PR corrects that in places visible to the user. For backwards
compatibility the cmd line switches still work as before, but there's
a preference to IANA. The RFC naming is labeled as to be retired
in the future.
In addition to 7d36ba9a2e which
added new SSLv2 ciphers to the ciphers file this commit adds those
ciphers also to those functions where needed.
Also it does some housekeeping. [[ doesn't require strings on
the right hand side to be quoted, see bash hackers wiki.
PR #1114 brought #1139 a good step forward. This commit adds
a few tweaks to it:
* the groups in run_pfs() are now also italic, except FFDHE groups
* renaming FF groups to DH groups to provide consistency with the
remainder of testssl.sh
* JSON identifier was renamed from DHE_groups to DH_GROUPS
Open points:
* in run_logjam() there's no warning at all regarding e.g. dh512.badssl.com.
Reading the Logjam paper in section 3.5., first couple of paragraphs we
should warn at least against 512 bits here too.
* how do we treat/label 768 bit and 1024 bit in run_logjam() which comes from
unknown groups? Looks like the paper only was concerned about precompuation.
* In run_logjam() is the bit length not colored but in run_pfs() it is.
* Notation: when do we label FF groups / DH parameter ephemeral?
* Code in run_pfs() and run_logjam() can be merged more.
run_logjam() is only related to TLSv1.2 and earlier ciphers. So, run_pfs() should only update $DH_GROUP_OFFERED if a DH group was found using a non-TLSv1.3 cipher.
On the other side, if run_logjam() happened to have been run first, and it found an ffdhe cipher, then there is no need for run_pfs() to test for it.
