There seem to be some server who don't provide proper handshake
results when we send the whole handshake data to them, including
ALPN.
So, what we do is removing the ALPN extension from the stream of
heax bytes when we test STARTTLS host. Plan is to do that for all
in `client_simulation_sockets()` also probably this won't be needed
for firefox and friends.
The approach is following:
We need to find the proper hexcode string in the passed data. Proper way would be going from
extension to extension with the top level length of each extension until we reach ALPN (0x10).
That seemed to difficult. We do that differently which has a threoretic catch as we might also
similar patterns -- but as we have the handshake data as hex we can make sure. What we do is
finding the leading bytes of the ALPN extension and concatenate all byte string we know of,
and match that. In addition we have the alpn+= text in the client simulation data to check against.
Scheme is alpn_ext, then come three lengths. We know each length so we can concatenate
all values and search for them, and additionally match the extensions with the text form
in TESTSSL_INSTALL_DIR/etc/client-simulation.txt.
The lengths are
- \#1: total length of extension
- \#2: same as above but minus 2
- \#3: the first extension length, i.e. 02 for h2 and 08 for http/1.1x"
also: next one is always an h (0x68).
This is a WIP.
It would fix#2410 when finished.
Under some circumstances the opossum vulnerability check got stuck
because the cat commdn was waiting for reading from the descriptor.
In some case like #2950 this happened when the HTTP head command
was incorrectly send in the first place.
This PR makes sure that the HTTP head is correct and it replaces
cat by read in a loop so that the HTTP response is read without
being blocked.
Also for http_head_printf() the argumensats passed were cleaned up.
`grep -w` matches also `string1-whatsoever` so that entries like
```
192.168.0.10 anystring anystring-apache
192.168.0.11 anystring-tomcat
```
matched 3 entries over 2 lines.
This PR fixes#2937 by improving the match pattern, so that
`string1` needs a trailing whitespace or a EOL -- besides a
leaing whitespace.
The new block making sure that rust coreutils work properly (PR #2913)
introduced a new check in order to determine which date functions
to use.
The function however parsed only for English error messages ("No such file").
This PR fixes that by setting LC_ALL to C.
Fixes#2929 .
and some warnings.
Five errors of type [SC2145](https://www.shellcheck.net/wiki/SC2145) are left as I am not sure whether
it'll be safe to follow the recommendation
This PR implements a check for TLS early data. It needs a compatible OpenSSL or
LibreSSL version. For modern OS versionis it should automagically pick the right,
modern binary for the check.
Mitigations like Defer processing or HTTP 425 are not yet tested.
To clarify is
* whether to penalize SSLlabs rating (@magnuslarsen). testssl.net has it
enabled but the Web UI claims it's not a/v, see
https://www.ssllabs.com/ssltest/analyze.html?d=testssl.net&s=172.67.205.231&hideResults=on&latest
* Man pages
To be in line with other HAS2_* global vars (HAS2_QUIC, HAS2_UDS), the following
vars were renamed from their OPENSSL2_HAS_* counter parts:
- HAS2_TLS13
- HAS2_CHACHA20=false
- HAS2_AES128_GCM=false
- HAS2_AES256_GCM=false
It seems needed to introduce two variables for upcoming early data tests,
see #1186. This is not needed for OpenSSL as it introduced that
together with TLS 1.3. For LibreSSL it is though.
* keys now always with v, like supportedciphers_TLSv1_2 and also
ciphers (e.g. TLSv1.2 x35 AES256-SHA)
* add word "server" to file output so that it reads "NOT a server cipher order configured"
Fixes#2884
As suggested in https://github.com/testssl/testssl.sh/pull/2885 parsing
of the server determined HTTP age var wasn't strict enough.
https://www.rfc-editor.org/rfc/rfc7234#section-1.2.1 requires the
variable to be a non-negative integer but testssl.sh assumed it was
like that but did't check whether that really was the case. This was
labled as a (potential) security problem. Potential as it didn't
look exploitable after review -- the header as a whole was already
sanitized.
This PR fixes the typs confusion and the garbled screen by checking
the variable early in run_http_header() and reset it to NaN. That
will be used later in run_http_date() to raise a low severity finding.
Kudos to @Tristanhx for catching this and for the suggested PR.
Also, only when running in debug mode, this PR fixes that during
service_detection() parts of the not-yet-sanitized header ended
up on the screen. The fix just calls sanitze_http_header() for the
temporary variable $TMPFILE.
... which leads to a performance gain., most noteably on Macs.
All times when calling were re-adjusted.
Also:
* PROXY_WAIT was decrease to 10 seconds. 20 seemed just too much
* passed var to `starttls_just_read()` was simplyfied
Dirk Wetter