Commit Graph

2844 Commits

Author SHA1 Message Date
4b6bdf8cdf More polishing of http basic auth
* Replace "! -z" with "-n"
* Replace "openssl' with "$OPENSSL"
* Redirect stderr output of $OPENSSL to /dev/null to supress "WARNING: can't open config file: /usr/local/etc/ssl/openssl.cnf" message (see #833)
* Remove unnecessary spaces from $GET_REQ11 string.
2020-01-16 13:41:27 -05:00
91e14a3840 Merge pull request #1452 from drwetter/add_1451
Last fine tuning for http basic auth
2020-01-16 16:34:09 +01:00
0691dc1bf8 Merge pull request #1453 from mkauschi/add-cache-control-header-check
Check for the Cache-Control and Pragma header
2020-01-16 16:25:18 +01:00
e498ffbdb2 add Pragma header to other_header_variable 2020-01-16 15:01:48 +01:00
5813e40e6b chore: add cache control header to other_header variable 2020-01-16 14:55:15 +01:00
4603d924be Last fine tuning for http basic auth
* create roff file and HTML
* add hint to $ENV

Avoid 1x subshell

See #1451.
2020-01-16 14:29:53 +01:00
ddd29dafdd instantiate BASICAUTH variable 2020-01-16 10:15:07 +01:00
51fb849954 change basicauth_header variable to a local variable 2020-01-16 10:13:16 +01:00
87b46a54fe add support for http basic auth 2020-01-15 16:46:03 +01:00
38a00f7170 Add one second for 825 day validity test
The CA browser form agreed on a validity period of 825 days or less
(https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.3-redlined.pdf,
p4).

PR #1427 addressed that. However when an issuer signed/issued a certificate
with exactly 825 days, the check reported incorrectly that the life time
is too long.

This commit addressed that by adding a second to the calulation. Also the
output takes into account that it must be over ('>') 825 days, not '>='.
2020-01-15 15:32:32 +01:00
2ed317441f Reimplement mitigation check (renegotiation->node.js)
See #1070, kudos @poupas.

In addition it checks whether the first result was positive (in
terms of a finding). If so it does 4 rounds and checks the
result. So that other servers won't be penalized with 4 seconds.
2020-01-15 12:11:57 +01:00
2a87f7505d Merge pull request #1445 from drwetter/alternative_temppath
Try temp file creation in a different location
2020-01-15 09:59:12 +01:00
50ea6b1891 $PWD check : negate pattern + add $BASH_REMATCH 2020-01-14 22:52:47 +01:00
50c9075ba8 Provide whitelist for $PWD
see #1445
2020-01-14 20:41:08 +01:00
f0f8f3a318 Remove TEMPPATH, make sure PWD doesn't contain a blank 2020-01-14 20:09:46 +01:00
477b113fe6 Add missing variable declarations
derive-handshake-traffic-keys() uses the variables `derived_secret`, `server_write_key`, and `server_write_iv`, but they are not declared as local variables of the function. This PR fixes that.
2020-01-14 13:53:36 -05:00
8518284795 Try temp file creation in a different location
... if the standard directory /tmp is not allowed to write to.
As noted in #1273 this might be the case for Termux on Android.
2020-01-14 18:55:09 +01:00
f181efb352 Don't write to /dev/stdout
As noted in #1273, there are some environments that will not allow writing to /dev/stdout. PR #1277 was an attempt to address that problem (along with an unrelated problem), but it appears that work on #1277 has been abandoned.

At the moment, "/dev/stdout" is only used as a parameter to asciihex_to_binary_file (in fact, most calls to asciihex_to_binary_file specify "/dev/stdout" as the file parameter). This PR removes the file parameter from asciihex_to_binary_file (and so renames it asciihex_to_binary). In most cases, this just means removing "/dev/stdout" as a parameter to the function. In the few cases in which a parameter other than "/dev/stdout" was provided to asciihex_to_binary_file, this PR just uses a redirect (">" or ">>") to accomplish the same result as providing the output file to asciihex_to_binary_file().

Note that #1273 and #1277 raised the issue of trying to write to /tmp, and this PR does not attempt to address that.
2020-01-14 09:10:23 -05:00
ee11ea408e bump version to final 2020-01-13 23:27:00 +01:00
855758b3af Fix run_server_preference() in --ssl-native mode
This PR fixes two problems that occur when testing a server that supports TLSv1.3 using OpenSSL 1.1.1 in --ssl-native mode.

First, when testing whether the server has a cipher order, the value of $sclient_success is checked after each call to tls_sockets(), but $sclient_success. As the goal is just to verify that the connection was successful (and didn't downgrade), $? can be checked rather than $sclient_success. [When not in --ssl-native mode, this problem is masked since $sclient_success is set to 0 earlier in the function.]

The second problem is that line 6646 tries to copy "$TEMPDIR/$NODEIP.parse_tls13_serverhello.txt", but this file is currently only created (on line 6287) if tls_sockets() is used to determine the negotiated protocol. This PR fixes the problem by also populating "$TEMPDIR/$NODEIP.parse_tls13_serverhello.txt" when OpenSSL is used to determine the negotiated protocol.
2020-01-13 10:51:34 -05:00
5c2a9772ea Avoid conflict of parallel mass scanning + connect timeouts
As stated in #1435 when specifying ``-connect-timeout=20`` AND
``--parallel`` there  asa problem with the file handles of child
processes (__testssl.sh: line 10454: 5: Bad file descriptor__).

This commit mitigates that in a sense that both switches can't
be used together. There's a check now in parse_cmd_line().

In addition it addresses a problem when fatal() is called and
e.g. JSON files haven't been created yet (error message ~
__testssl.sh: line 825: : No such file or directory__). It
introduces a global CMDLINE_PARSED which remembers the state
whether ``parse_cmd_line()`` has been fully executed or
not. Only when the former is the case it allows writing to files.
That implies that in main parse_cmd_line() has to be followed
by json_header() and similar.
2020-01-13 10:58:25 +01:00
b70407352d Merge branch '3.0' into fix_1429 2020-01-09 14:00:11 +01:00
34784b6c6a Fix HTTP time for recent OpenBSD
See #1429.
OpenBSD 6.6 had an offset with the HTTP header time of  -3600 seconds.
This PR fixes that by adding the GMT time zone to parse_date()'s
HAS_FREEBSDDATE incarnation. That doesn't matter to FreeBSD.

Also now for older OpenBSDs the local and remote time are now
in the same format:

```
HTTP clock skew              remote: Thu, 09 Jan 2020 12:52:32 GMT
                             local:  Thu, 09 Jan 2020 12:52:02 GMT
``

so that a time difference is easier to spot.
2020-01-09 13:52:28 +01:00
21f87d7266 Fixes missing display of HTTP headers under OpenBSDs
OpenBSD's grep seems to interpret "-w <EXPR>:" differently
than Linux or MacOSX/FreeBSD in a sense that this doesn't
matchs, see #1430.

This PR fixes that by squashing the w option in all occuorrences.

In addition it removes the SOCKETHEADER if-statement which was
introduced looking forward a while back. It's not happening soon
at least and the variable was not initialized either.
2020-01-08 15:51:21 +01:00
e319d6c01f Merge pull request #1428 from drwetter/correct_warningsoption
Remove --warnings=false from documenation
2020-01-08 14:33:37 +01:00
256d4d32ab Merge pull request #1427 from drwetter/825_days
Check for certificates with a life time >825 days when issued after 2018/03/01
2020-01-08 14:31:19 +01:00
c228b578dd Remove --warnings=false from documenation
... and reorder manpages also so that --warnings, --connect-timeout
and --openssl-timeout appear in the "input parameter" section.

The HTML manpage looks in the diff view quite different as previously
another computer was used for converting the source format with ronn(1).

The manpage in (g)roff format was manually edited with .RE / .RS
for provide indented bulletpoints.

See also #1419
2020-01-08 14:24:41 +01:00
b2680db162 Finalize 825 day check, add more OpenBSD date improvements
* It'll be a warning now when a host certificate was issued after
  March 1st, 2018 which has a lifetime >825 days, independent
  whether it is an internal certificate or not. This can
  change later, as browsers treat those certificates different
  as "official ones"
* Still the 5 or 10 year threshold overrides this
* For older OpenBSDs there's now a better date format support
  used in the expiration and validity period of a host certificate.
  It mimics in bash the conversion of other date binaries. It is
  not accurate so it might be off a day or at maximum two, probably
  as a month has 30.42 days and not 30.
* The date output for OpenBSD is now in line with other OS. Previously
  we just echoed the lines in openssl x509 output whereas now we
  convert that
2020-01-08 11:23:11 +01:00
35e6adccc4 Fix bits errors in OpenBSDs
The expression 'grep -aw "Public-Key:"' hiccuped on the colon
under OpenBSD, so that any bitsize on a certificate had wrong
values, see #1425. (FreeBSD was fine)

This PR fixes that. It updates the expression by using awk and
bash internal functions.

The same problem occured in run_robot(). The strong typing of
pubkeybits had to be relaxed to a dynamic typing, unless we
choose to define a second string variable.
2020-01-08 10:56:45 +01:00
a42b98c0ff Save work
* old OpenBSD kinda works
* let's encrypt section moved so that OpenBSD can use it too

* Days are wrong
* Date format is not the same as with e.g. GNUdate (but should be)
* variables y m d not declared
* date warning for openbsd completely missing
2020-01-07 13:56:08 +01:00
e9108baf93 correct comment 2020-01-04 11:22:45 +01:00
c80a1307bf Detect 825 days threshold for certificates issued >2018/03/01
... as mentioned #1422

Open
* testing
* openbsd
2020-01-04 11:18:46 +01:00
0e5376042b cert_validityPeriod is wrong. 2020-01-03 16:30:40 +01:00
1bc50bb7d3 Merge pull request #1421 from drwetter/fix_1418
Fix s_client capability test for LLMNR, add HAS_PKEY
2020-01-02 17:21:48 +01:00
accdb3d4f6 Fix s_client capability tet for LLMNR, add HAS_PKEY
As noted in #1418 LLMNR (Link-Local Multicast Name Resolution)
resolution times out when using x as an argument to "-connect".

This commit fixes that by replacing "-connect x" by "-connect invalid."
which is supposedly also generally more "DNS query friendly", see
https://tools.ietf.org/html/rfc6761#section-6.4 .

In addition this commit adds a check in get_common_prime() whether
the openssl version used has pkey support. If not with old openssl
versions and previously testssl.sh terminated after presenting garbledoutput.
(This was found as tested how very old version of openssl versions
handle "-connect invalid.")
2020-01-02 16:16:54 +01:00
7c1b8139b2 Minor tweak to run_tls_fallback_scsv()
If the server is known not to support TLS 1.3 (as well as TLS 1.2, TLS 1.1, and TLS 1), then mention TLS 1.3 in the list of not supported protocols. While lack of TLS 1.3 support is not part of the reason that no fallback is possible, it is part of the reason that the result is reported as prln_svrty_high.
2019-12-27 09:33:08 -05:00
a0b2fb5d56 Minor tweak to run_tls_fallback_scsv()
Don't report "OK" if the server may be TLS 1.3-only or SSLv3-only, as one is very good and one is very bad.
2019-12-27 09:33:08 -05:00
3f25bcc6d4 Minor tweaks to run_tls_fallback_scsv() 2019-12-27 09:33:08 -05:00
e457ff8cc1 Improve check for $low_proto in run_tls_fallback_scsv()
If $high_proto is set to something other than SSLv3, support for SSLv3 will not have been determined by determine_optimal_sockets_params(), but it may have been determined later (e.g., by run_protocols()). So, this commit changes the loop to always check for SSLv3 support (without calling "$OPENSSL s_client" if $HAS_SSL3 is false). The check for whether the fallback test can be performed is moved until after the loop
2019-12-27 09:33:08 -05:00
00f613f62d WIP: Don't call s_client for unsupported protocol versions
This PR fixes a couple of places where "$OPENSSL s_client" is called with "-ssl3" even if SSLv3 is not supported.

The fix in ciphers_by_strength() is easy, as the issue only occurs if "$using_sockets" is true. If SSLv3 (or TLSv1.3) is not supported, then testing using "$OPENSSL s_client" is skipped and all of the supported ciphers are found using tls_sockets().

The fix for run_tls_fallback_scsv() is more complicated. While it is easy to avoid calling "$OPENSSL s_client" with "-ssl3" if SSLv3 is not supported, it is not easy to determine the correct message to present to the user if support for SSLv3 (and possibly also TLSv1.3) is unknown.

For the case in which $high_proto cannot be set, I believe that I have covered all of the possibilities, but an not sure if the correct message/rating is used in every case.

For the case in which it is not possible to determine whether SSLv3 is the $low_proto, more could be done. If $high_proto is TLS 1.1 or TLS 1, then this PR is okay, as it is possible that SSLv3 would be the fallback protocol, but there is no way to tell. However, it seems unlikely that a server would support TLS 1.2 and SSLv3, but not TLS 1.1 or TLS 1. So, perhaps if $high_proto is TLS 1.2 and the server does not support TLS 1.1 or TLS 1, it should just be assumed that SSLv3 is not supported, even if it cannot be tested.
2019-12-27 09:33:08 -05:00
fa5bb18d15 Merge pull request #1416 from drwetter/cipher-categories
Bring pr_cipher_quality() and run_cipherlists() in line
2019-12-24 11:47:41 +01:00
ce4f923c6b Fix TLS 1.3 key derivation
At the moment, testssl.sh does not correctly derive the handshake traffic keys in the case that the server responds to the initial ClientHello with a HelloRetryRequest. The handshake traffic keys are computed incorrectly because the wrong messages are provided to derive-handshake-traffic-keys() for input to the Transcript-Hash calculation:

* TLS_CLIENT_HELLO is not updated to contain the value of the second ClientHello, and so the first ClientHello is being provided to derive-handshake-traffic-keys() as both the first and the second ClientHello.

* In middlebox compatibility mode the server may send a dummy ChangeCipherSpec message immediately after the HelloRetryRequest. Since it is part of the server's response to the initial ClientHello, the ChangeCipherSpec message is included in the $hrr that is sent to derive-handshake-traffic-keys(), but it should not be included in the computation of the Transcript-Hash.

This PR fixes the above two problems by updating TLS_CLIENT_HELLO when a second ClientHello is sent and by removing any ChangeCipherSpec message (140303000101) from the end of the server's initial response.
2019-12-23 15:37:26 -05:00
70112a989e Bring pr_cipher_quality() and run_cipherlists() in line
* Severity of RC4 in run_cipherlists() is now high as everywhere else
* Same for RC2 and DES. Only Export, NULL and ADH remain critical
* 3DES and IDEA in run_cipherlists() is now medium (see #1393)
* CBC3  SEED 3DES IDEA added in pr_cipher_quality()
* MD5 added to pr_cipher_quality() and labled as high
* double RC2 switch statemnet removed in pr_cipher_quality()
2019-12-22 14:41:39 +01:00
710f915660 update version 2019-12-12 11:34:33 +01:00
c960bd16f9 fix errorneous insertion 2019-12-11 22:20:58 +01:00
849a41a371 Minor internal code improvements
* rename actually_supported_ciphers() to actually_supported_osslciphers()
* remove some redundant quotes at rhs of double brackets checks
2019-12-11 22:07:53 +01:00
055a2e9bb4 --connect-timeout finalized
* openssl timeout tested
* one openssl related error message fixed when timeout is used (timeout was included)
2019-12-10 21:02:32 +01:00
20e77318ca Further improving socket connect timeout
* Handle case when "timeout" couldn't be found
* Proper error message when timeout requested but isn't available
* Fix errorneous message in help()
2019-12-10 13:18:45 +01:00
8e02b4a261 Improvements to socket timeouts
* timeouts are not default anymore but need a cmdline param (or ENV param)
* check whether "timeout" exists

Also:
* allow OPENSSL_TIMEOUT to be passed via ENV similar to others
* replace timeout variable in run_robot() by robottimeout, to avoid
  misunderstandings by a human

ToDos: see inline. Mainly if timeout isn't available, testssl.sh doesn't
work.

Not to self: help function still says 60 second is default.
2019-12-09 10:47:58 +01:00
b1f4713287 Merge branch '3.0' of https://github.com/goncalor/testssl.sh into goncalor-3.0 2019-12-06 16:29:45 +01:00