see #2325. This is for the 3.0 branch (for 3.1dev see #2326)
"whenever HTTP/1.1 is used then the Accept header uses "text/*" as a MIME type.
This causes some minor issues with some of the checks we are doing"
The actions release numbers were taken from the 3.1dev branch.
Note: there was one strange codespell error in PR #2263.
Maybe the updated action will avoid this in the future.
see #2169, #2168
Added:
* Safari for macOS
* Java 17 LTS
* OpenSSL 3.0.3
* Android 11 and 12
* Go client (1.17)
* Firefox 100, Chrome and Edge 101 using Win10
* Thunderbird 91.9
* AppleMail
* LibreSSL from MacOS
* disabled Java 12 and Safari on OS X 10.12
* disabled Android < 6.0
* documention update how to add a client simulation
* add curves-mapping.txt file
On macOS in dark mode the git tag in grey wasn't visible. It was
changed now to light grey. It also works at least on Linux
using a light terminal background.
The NNTP server which we used for STARTTLS checks seems ofen
not to work. Thus this PR removes that for the 3.0 branch.
In rare? occassions where the STARTTLS FEAT request only displays AUTH instead
of AUTH TLS, testssl.sh fails as it cannot upgrade to TLS.
Required by RFC 4217 is only AUTH ("MUST"), AUTH TLS is optional ("should"), see section 6.
This PR relaxes the presence of TLS after AUTH and fixes#2132 for the 3.0 branch.
Under Darwin using LibreSSL it was not possible to test for session
resumption by session ID.
This fixes the issue #2096 for 3.0 by checking not only the return value of the
s_client hello but also whether a probable certificate is being returned.
It is now being tested whether the binary locale exists and
there's a global introduced for that.
Also there's no fileout warning at this early stage anymore
as it leads to non-valid JSON
Therefore a new global function was declared checking whether any of
the known locales work on the client without seeting them.
C / POSIX should work as well for LC_COLLATE.
This fixes#2100 for 3.0 .
This PR addresses a bug where a user encountered the question "The results
might look ok but they could be nonsense. Really proceed".
That happened under Darwin and probably some LibreSSL versions when
checking some hosts. sclient_auth() returned 1 indicating no SSL/TLS
handshake could be established.
This PR modifies sclient_auth() so that in those cases 0 is returned by
skipping the check for the session ID. As NO_SSL_SESSIONID needs to
be set when there's no session ID. This is done separately.
This fixes#2052 for 3.0
See #2032 / #2067, kudos @Wahnes. This is a backport for 3.0
Currently, when "HTTP clock skew" is calculated, this is taken to be the
difference between the timestamp of the moment the HTTPS request was sent and
the date given in the HTTP Date header. This does not yield valid results in
case a HTTP cache is used, either on the client side or on the server side.
According to the HTTP specs, the Date field will contain the timestamp the
response was created, which may not be the timestamp the response was
delivered.
Consider the following example that queries the Varnish project's web server.
Note that Varnish is a popular HTTP caching server, so HTTP caching will of
course be used when serving HTTP responses from this project's web server.
testssl.sh https://varnish-cache.org/ This will typically output a HTTP clock
skew of some thousand seconds.
The patch takes into account the HTTP Age header that caching servers add to
the HTTP response to signal the response's freshness. As client-side caches
normally do not cache HTTPS requests (except maybe for "enterprise" HTTP proxy
caches that do MITM HTTPS proxying), this is mostly targeted to HTTPS websites
that employ server side HTTP caching.
Addtional polishing:
* address my comments in #2032
* add JSON field HTTP_headerAge if they exists
* output HTTP_AGE if it was detected
* do stripping of line feeds closer to where variables were set
This fixes#1834 and #1435 for branch 3.0. (3.1dev: #2047)
The --connect-timeout option had the problem that under certain circumstances
like parallel mass scanning didn't work. The culprit was that a subshell command
was used to connect to the target but the file descriptor wasn't exported.
The PR changes the logic so that the connect pre-check is still done in a subshell
If this fails it proceeds with error handling if NR_SOCKET_FAIL is above threshold.
Otherwise it just connects again.
Dirk Wetter