If lsof is not available, wait_server_start uses a fixed timeout,
which can trigger a race condition if the timeout turns out to be too
short. Emit a warning so that we know this is going on from the test
logs.
- Some of the CI machines don't have lsof installed yet, so rely on an sleeping
an arbitrary number of seconds while the server starts. We're seeing
occasional failures with the current delay because the CI machines are highly
loaded, which seems to indicate the current delay is not quite enough, but
hopefully not to far either, so double it.
- While at it, also double the watchdog delay: while I don't remember seeing
much failures due to client timeout, this change doesn't impact normal
running time of the script, so better err on the safe side.
These changes don't affect the test and should only affect the false positive
rate coming from the test framework in those scripts.
In wait_server_start, fork less. When lsof is present, call it on the
expected process. This saves a few percent of execution time on a
lightly loaded machine. Also, sleep for a short duration rather than
using a tight loop.
Add a DTLS small packet test for each of the following combinations:
- DTLS version: 1.0 or 1.2
- Encrypt then MAC extension enabled
- Truncated HMAC extension enabled
Large packets tests for DTLS are currently not possible due to parameter
constraints in ssl_server2.
This commit ensures that there is a small packet test for at least any
combination of
- SSL/TLS version: SSLv3, TLS 1.0, TLS 1.1 or TLS 1.2
- Stream cipher (RC4) or Block cipher (AES)
- Usage of Encrypt then MAC extension [TLS only]
- Usage of truncated HMAC extension [TLS only]
Noticed that the test cases in ssl-opt.sh exercising the truncated HMAC
extension do not depend on MBEDTLS_SSL_TRUNCATED_HMAC being enabled in
config.h. This commit fixes this.
Previously, MAC validation for an incoming record proceeded as follows:
1) Make a copy of the MAC contained in the record;
2) Compute the expected MAC in place, overwriting the presented one;
3) Compare both.
This resulted in a record buffer overflow if truncated MAC was used, as in this
case the record buffer only reserved 10 bytes for the MAC, but the MAC
computation routine in 2) always wrote a full digest.
For specially crafted records, this could be used to perform a controlled write of
up to 6 bytes past the boundary of the heap buffer holding the record, thereby
corrupting the heap structures and potentially leading to a crash or remote code
execution.
This commit fixes this by making the following change:
1) Compute the expected MAC in a temporary buffer that has the size of the
underlying message digest.
2) Compare to this to the MAC contained in the record, potentially
restricting to the first 10 bytes if truncated HMAC is used.
A similar fix is applied to the encryption routine `ssl_encrypt_buf`.
This commit adds regression tests for the bug when we didn't parse the
Signature Algorithm extension when renegotiating. (By nature, this bug
affected only the server)
The tests check for the fallback hash (SHA1) in the server log to detect
that the Signature Algorithm extension hasn't been parsed at least in
one of the handshakes.
A more direct way of testing is not possible with the current test
framework, since the Signature Algorithm extension is parsed in the
first handshake and any corresponding debug message is present in the
logs.
This commit adds regression tests for the bug when we didn't parse the
Signature Algorithm extension when renegotiating. (By nature, this bug
affected only the server)
The tests check for the fallback hash (SHA1) in the server log to detect
that the Signature Algorithm extension hasn't been parsed at least in
one of the handshakes.
A more direct way of testing is not possible with the current test
framework, since the Signature Algorithm extension is parsed in the
first handshake and any corresponding debug message is present in the
logs.
Add a test to ssl-opt.sh that parses the client and server debug
output and then checks that the Unix timestamp in the ServerHello
message is within acceptable bounds.
Extend the run_test function in ssl-opt.sh so that it accepts the -f
and -F options. These parameters take an argument which is the name of
a shell function that will be called by run_test and will be given the
client input and output debug log. The idea is that these functions are
defined by each test and they can be used to do some custom check
beyon those allowed by the pattern matching capabilities of the
run_test function.
Add a test to ssl-opt.sh that parses the client and server debug
output and then checks that the Unix timestamp in the ServerHello
message is within acceptable bounds.
Extend the run_test function in ssl-opt.sh so that it accepts the -f
and -F options. These parameters take an argument which is the name of
a shell function that will be called by run_test and will be given the
client input and output debug log. The idea is that these functions are
defined by each test and they can be used to do some custom check
beyon those allowed by the pattern matching capabilities of the
run_test function.
Some tests in ssl-opt.sh require MBEDTLS_SSL_MAX_CONTENT_LEN to be set to its
default value of 16384 to succeed. While ideally such a dependency should not
exist, as a short-term remedy this commit adds a small check that will at least
lead to graceful exit if that assumption is violated.
This commit adds four tests to ssl-opt.sh testing the library's behavior when
`mbedtls_ssl_write` is called with messages beyond 16384 bytes. The combinations
tested are TLS vs. DTLS and MBEDTLS_SSL_MAX_FRAGMENT_LENGTH enabled vs. disabled.
The tests only work for a specific number for MBEDTLS_X509_MAX_INTERMEDIATE_CA
so the check has been changed to confirm the default value, and to show an error
otherwise.
Some tests in ssl-opt.sh assumes the value 8 for the maximal number
MBEDTLS_X509_MAX_INTERMEDIATE_CA of intermediate CA's. This commit adds a check
before conducting the respective tests.
This commit adds four tests to tests/ssl-opt.sh:
(1) & (2): Check behaviour of optional/required verification when the
trusted CA chain is empty.
(3) & (4): Check behaviour of optional/required verification when the
client receives a server certificate with an unsupported curve.
