A lot of DTLS test are timing-sensitive, especially those that contain
assertions about retransmission. Sometimes some DTLS test fails intermittently
on the CI with no clear apparent reason; we need more information in the log
to understand the cause of those failures.
Adding a proxy means we'll get timing information from the proxy logs.
An alternative would be to add timing information to the debug output of
ssl_server2 and ssl_client2. But that's more complex because getting
sub-second timing info is outside the scope of the C standard, and our current
timing module only provides a APi for sub-second intervals, not absolute time.
Using the proxy is easier as it's a single point that sees all messages, so
elapsed time is fine here, and it's already implemented in the proxy output.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This commit introduces two changes:
- Add in_msg and out_msg calculations for buffer upsizing. This was previously
considered as unnecessary, but renegotiation using certain ciphersuites needs
this.
- Improving the way out_msg and in_msg pointers are calculated, so that even
if no resizing is introduced, the pointers remain the same;
New tests added:
- various renegotiation schemes with a range of MFL's and ciphersuites;
- an ssl-opt.sh test exercising two things that were problematic: renegotiation
with TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8 and a server MFL that's smaller
than the one negotiated by the client.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Since the server might want to have a different maximum fragment length
for the outgoing messages than the negotiated one - introduce a new way of
computing it. This commit also adds additional ssl-opt.sh tests ensuring
that the maximum fragment lengths are set as expected.
mbedtls_ssl_get_max_frag_len() is now a deprecated function,
being an alias to mbedtls_ssl_get_output_max_frag_len(). The behaviour
of this function is the same as before.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
There are currently 4 tests in ssl-opt.sh with either -C "resend" or -S
"resend", that is, asserting that no retransmission will occur. They sometimes
fail on loaded CI machines as one side doesn't send a message fast enough,
causing the other side to retransmit, causing the test to fail.
(For the "reconnect" test there was an other issue causing random failures,
fixed in a previous commit, but even after that fix the test would still
sometimes randomly fail, even if much more rarely.)
While it's a hard problem to fix in a general and perfect way, in practice the
probability of failures can be drastically reduced by making the timeout
values much larger.
For some tests, where retransmissions are actually expected, this would have
the negative effect of increasing the average running time of the test, as
each side would wait for longer before it starts retransmission, so we have a
trade-off between average running time and probability of spurious failures.
But for tests where retransmission is not expected, there is no such trade-off
as the expected running time of the test (assuming the code is correct most of
the time) is not impacted by the timeout value. So the only negative effect of
increasing the timeout value is on the worst-case running time on the test,
which is much less important, as test should only fail quite rarely.
This commit addresses the easy case of tests that don't expect retransmission
by increasing the value of their timeout range to 10s-20s. This value
corresponds to the value used for tests that assert `-S "autoreduction"` which
are in the same case and where the current value seems acceptable so far.
It also represents an increase, compared to the values before this commit, of
a factor 20 for the "reconnect" tests which were frequently observed to fail
in the CI, and of a factor 10 for the first two "DTLS proxy" tests, which were
observed to fail much less frequently, so hopefully the new values are enough
to reduce the probability of spurious failures to an acceptable level.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The server must check client reachability (we chose to do that by checking a
cookie) before destroying the existing association (RFC 6347 section 4.2.8).
Let's make sure we do, by having a proxy-in-the-middle inject a ClientHello -
the server should notice, but not destroy the connection.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- "Default" should only be used for tests that actually use the defaults (ie,
not passing options on the command line, except maybe debug/dtls)
- All tests in the "Encrypt then MAC" group should start with that string as a
common prefix
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The ssl-opt.sh test cases using session resumption tend to fail occasionally
on the CI due to a race condition in how ssl_server2 and ssl_client2 handle
the reconnection cycle.
The server does the following in order:
- S1 send application data
- S2 send a close_notify alert
- S3 close the client socket
- S4 wait for a "new connection" (actually a new datagram)
- S5 start a handshake
The client does the following in order:
- C1 wait for and read application data from the server
- C2 send a close_notify alert
- C3 close the server socket
- C4 reset session data and re-open a server socket
- C5 start a handshake
If the client has been able to send the close_notify (C2) and if has been
delivered to the server before if closes the client socket (S3), when the
server reaches S4, the datagram that we start the new connection will be the
ClientHello and everything will be fine.
However if S3 wins the race and happens before the close_notify is delivered,
in S4 the close_notify is what will be seen as the first datagram in a new
connection, and then in S5 this will rightfully be rejected as not being a
valid ClientHello and the server will close the connection (and go wait for
another one). The client will then fail to read from the socket and exit
non-zero and the ssl-opt.sh harness will correctly report this as a failure.
In order to avoid this race condition in test using ssl_client2 and
ssl_server2, this commits introduces a new command-line option
skip_close_notify to ssl_client2 and uses it in all ssl-opt.sh tests that use
session resumption with DTLS and ssl_server2.
This works because ssl_server2 knows how many messages it expects in each
direction and in what order, and closes the connection after that rather than
relying on close_notify (which is also why there was a race in the first
place).
Tests that use another server (in practice there are two of them, using
OpenSSL as a server) wouldn't work with skip_close_notify, as the server won't
close the connection until the client sends a close_notify, but for the same
reason they don't need it (there is no race between receiving close_notify and
closing as the former is the cause of the later).
An alternative approach would be to make ssl_server2 keep the connection open
until it receives a close_notify. Unfortunately it creates problems for tests
where we simulate a lossy network, as the close_notify could be lost (and the
client can't retransmit it). We could modify udp_proxy with an option to never
drop alert messages, but when TLS 1.3 comes that would no longer work as the
type of messages will be encrypted.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The splitting of this test into two versions depending on whether SHA-1 was
allowed by the server was a mistake in
5d2511c4d4 - the test has nothing to do with
SHA-1 in the first place, as the server doesn't request a certificate from
the client so it doesn't matter if the server accepts SHA-1 or not.
While the whole script makes (often implicit) assumptions about the version of
GnuTLS used, generally speaking it should work out of the box with the version
packaged on our reference testing platform, which is Ubuntu 16.04 so far.
With the update from Jan 8 2020 (3.4.10-4ubuntu1.6), the patches for rejecting
SHA-1 in certificate signatures were backported, so we should avoid presenting
SHA-1 signed certificates to a GnuTLS peer in ssl-opt.sh.
* origin/pr/2843: (26 commits)
Make hyperlink a hyperlink in every markdown flavor
Update the crypto submodule to be the same as development
Document test case descriptions
Restore MBEDTLS_TEST_OUTCOME_FILE after test_default_out_of_box
ssl-opt.sh: Fix some test case descriptions
Reject non-ASCII characters in test case descriptions
Process input files as binary
Factor description-checking code into a common function
Fix cosmetic error in warnings
Fix regex matching run_test calls in ssl-opt.sh
all.sh: run check-test-cases.py
Better information messages for quick checks
Fix configuration short name in key-exchanges.pl
Make test case descriptions unique
New test script check-test-cases.py
Document the test outcome file
Create infrastructure for architecture documents in Markdown
all.sh --outcome-file creates an outcome file
Set meaningful test configuration names when running tests
ssl-opt: remove semicolons from test case descriptions
...
Fix copypasta in some test cases with
MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES enabled.
Add unique suffix to the two
"DTLS fragmenting: proxy MTU: auto-reduction" test cases.
Don't use semicolons in test case descriptions. The test outcome file
is a semicolon-separated CSV file without quotes to keep things
simple, so fields in that file may not contain semicolons.
If the environment variable MBEDTLS_TEST_OUTCOME_FILE is set, then for
each test case, write a line to the file with the given name, of the
form
PLATFORM;CONFIGURATION;ssl-opt;TEST CASE DESCRIPTION;PASS/FAIL/SKIP;CAUSE
PLATFORM and CONFIGURATION come from the environment variables
MBEDTLS_TEST_PLATFORM and MBEDTLS_TEST_CONFIGURATION. If these
variables are unset, the script uses some easily-calculated values.
git grep -Fl /config.pl | xargs sed -i -e 's!/config\.pl!/config.py!g'
Also:
* Change one comment in include/mbedtls/check_config.h.
* Change PERL to PYTHON in CMakeLists.txt.
This commit splits each test in ssl-opt.sh related to context serialization
in three tests, exercising the use of CCM, GCM and ChaChaPoly separately.
The reason is that the choice of primitive affects the presence and size
of an explicit IV, and we should test that space for those IVs is correctly
restored during context deserialization; in fact, this was not the case
previously, as fixed in the last commit, and was not caught by the tests
because only ChaChaPoly was tested.
The size of the ticket used in this test dropped from 192 to 143 bytes, so
move all sizes used in this test down 50 bytes. Also, we now need to adapt the
server response size as the default size would otherwise collide with the new
mtu value.
While 'session hash' is currently unique, so suitable to prove that the
intended code path has been taken, it's a generic enough phrase that in the
future we might add other debug messages containing it in completely unrelated
code paths. In order to future-proof the accuracy of the test, let's use a
more specific string.
It happens regularly in test runs that the server example application
shuts down a connection, goes into waiting mode for a new connection,
and then receives the encrypted ClosureAlert from the client. The only
reason why this does currently not trigger the 'record from another epoch'
message is that we handle ClientHello parsing outside of the main record
stack because we want to be able to detect SSLv2 ClientHellos. However,
this is likely to go away, and once it happens, we'll see the log message.
Further, when record checking is used, every record, including the mentioned
closure alert, is passed to the record checking API before being passed to
the rest of the stack, which leads to the log message being printed.
In summary, grepping for 'record from another epoch' is a fragile way
of checking whether a reordered message has arrived. A more reliable
way is to grep for 'Buffer record from epoch' which is printed when
a record from a future epoch is actually buffered, and 'ssl_buffer_message'
which is the function buffering a future handshake message.
Limit log output in compat.sh and ssl-opt.sh, in case of failures with these
scripts where they may output seemingly unlimited length error logs.
Note that ulimit -f uses units of 512 bytes, so we use 10 * 1024 * 1024 * 2 to
get 10 GiB.
* origin/pr/2260:
Update crypto submodule
Remove heading spaces in tests/data_files/Makefile
Re-generate library/certs.c from script
Add new line at the end of test-ca2.key.enc
Use strict syntax to annotate origin of test data in certs.c
Add run to all.sh exercising !MBEDTLS_PEM_PARSE_C + !MBEDTLS_FS_IO
Allow DHM self test to run without MBEDTLS_PEM_PARSE_C
ssl-opt.sh: Auto-skip tests that use files if MBEDTLS_FS_IO unset
Document origin of hardcoded certificates in library/certs.c
Adapt ChangeLog
Rename server1.der to server1.crt.der
Add DER encoded files to git tree
Add build instructions to generate DER versions of CRTs and keys
Document "none" value for ca_path/ca_file in ssl_client2/ssl_server2
ssl_server2: Skip CA setup if `ca_path` or `ca_file` argument "none"
ssl_client2: Skip CA setup if `ca_path` or `ca_file` argument "none"
Correct white spaces in ssl_server2 and ssl_client2
Adapt ssl_client2 to parse DER encoded test CRTs if PEM is disabled
Adapt ssl_server2 to parse DER encoded test CRTs if PEM is disabled
This commit temporarily comments the copying of the negotiated CIDs
into the established ::mbedtls_ssl_transform in mbedtls_ssl_derive_keys()
until the CID feature has been fully implemented.
While mbedtls_ssl_decrypt_buf() and mbedtls_ssl_encrypt_buf() do
support CID-based record protection by now and can be unit tested,
the following two changes in the rest of the stack are still missing
before CID-based record protection can be integrated:
- Parsing of CIDs in incoming records.
- Allowing the new CID record content type for incoming records.
- Dealing with a change of record content type during record
decryption.
Further, since mbedtls_ssl_get_peer_cid() judges the use of CIDs by
the CID fields in the currently transforms, this change also requires
temporarily disabling some grepping for ssl_client2 / ssl_server2
debug output in ssl-opt.sh.
requires_config_enabled doesn't support multiple config options.
Tests having multiple configuration dependencies must be prefixed
with multiple invocations of requires_config_enabled instead.
Resolve conflicts by performing the following:
- Ensure calls to mbedtls_x509_crt_verify_* are made with callbacks
* origin/pr/2539:
Make CRT callback tests more robust
Rename constant in client2.c
Fix typo
Add test for configuration specific CRT callback
Fix doxygen documentation of mbedtls_ssl_set_verify()
Add test exercising context-specific CRT callback to ssl-opt.sh
Add cmd to use context-specific CRT callback in ssl_client2
Implement context-specific verification callbacks
Add context-specific CRT verification callbacks
Improve documentation of mbedtls_ssl_conf_verify()
* origin/pr/2532: (29 commits)
Document and test flags in x509_verify
Fix style issues and a typo
Fix name to function call
Address comments for x509 tests
Address review comments regarding ssl_client2 and ssl tests
Remove mbedtls_ from the static function name
Change docs according to review comments
Change the verify function naming
Fix ssl_client2 and ssl_server2 if !PLATFORM_C
Correct placement of usage macro in ssl_client2
Update version_features.c
Remove trailing whitespace in test_suite_x509parse.function
Update query_config.c
Add ssl-opt.sh tests for trusted CA callbacks
Only run X.509 CRT verification tests with CA callback tests if !CRL
Minor fixes to CA callback tests
Declare CA callback type even if feature is disabled
Implement X.509 CRT verification using CA callback
Add prototype for CRT verification with static and dynamic CA list
Make use of CA callback if present when verifying peer CRT chain
...
* origin/pr/1520:
Use certificates from data_files and refer them
Specify server certificate to use in SHA-1 test
refactor CA and SRV certificates into separate blocks
refactor SHA-1 certificate defintions and assignment
refactor server SHA-1 certificate definition into a new block
define TEST_SRV_CRT_RSA_SOME in similar logic to TEST_CA_CRT_RSA_SOME
server SHA-256 certificate now follows the same logic as CA SHA-256 certificate
add entry to ChangeLog
* restricted/pr/528:
Update query_config.c
Fix failure in SSLv3 per-version suites test
Adjust DES exclude lists in test scripts
Clarify 3DES changes in ChangeLog
Fix documentation for 3DES removal
Exclude 3DES tests in test scripts
Fix wording of ChangeLog and 3DES_REMOVE docs
Reduce priority of 3DES ciphersuites
The test used 3DES as the suite for SSLv3, which now makes the handshake fails
with "no ciphersuite in common", failing the test as well. Use Camellia
instead (as there are not enough AES ciphersuites before TLS 1.2 to
distinguish between the 3 versions).
Document some dependencies, but not all. Just trying to avoid introducing new
issues by using a new cipher here, not trying to make it perfect, which is a
much larger task out of scope of this commit.
Additional work done as part of merge:
- Run ./tests/scripts/check-generated-files.sh and check in the
resulting changes to programs/ssl/query_config.c
Additional changes to temporarily enable running tests:
ssl_srv.c and test_suite_ecdh use mbedtls_ecp_group_load instead of
mbedtls_ecdh_setup
test_suite_ctr_drbg uses mbedtls_ctr_drbg_update instead of
mbedtls_ctr_drbg_update_ret
Don't bail out of all.sh if the OS isn't Linux. We only expect
everything to pass on a recent Linux x86_64, but it's useful to call
all.sh to run some components on any platform.
In all.sh, always run both MemorySanitizer and Valgrind. Valgrind is
slower than ASan and MSan but finds some things that they don't.
Run MSan unconditionally, not just on Linux/x86_64. MSan is supported
on some other OSes and CPUs these days.
Use `all.sh --except test_memsan` if you want to omit MSan because it
isn't supported on your platform. Use `all.sh --except test_memcheck`
if you want to omit Valgrind because it's too slow.
Make the test scripts more portable (tested on FreeBSD): don't insist
on GNU sed, and recognize amd64 as well as x86_64 for `uname -m`. The
`make` utility must still be GNU make.
So far, make sure we test the following ciphersuites
without any fallback to non-PSA ciphers:
TLS-ECDHE-ECDSA-WITH-AES-128-CCM
TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8
TLS-ECDHE-ECDSA-WITH-AES-256-CCM
TLS-ECDHE-ECDSA-WITH-AES-256-CCM-8
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
Previously, command line arguments `psk_slot` and `psk_list_slot`
could be used to indicate the PSA key slots that the example
applications should use to store the PSK(s) provided.
This commit changes this approach to use the utility function
`mbedtls_psa_get_free_key_slot()` to obtain free key slots from
the PSA Crypto implementation automatically, so that users only
need to pass boolean flags `psk_opaque` and `psk_list_opaque`
on the command line to enable / disable PSA-based opaque PSKs.
* development:
ssl-opt.sh: change expected output for large srv packet test with SSLv3
Adapt ChangeLog
Fix bug in SSL ticket implementation removing keys of age < 1s
ssl-opt.sh: Add DTLS session resumption tests
Add ChangeLog entry
Fix typo
Fix hmac_drbg failure in benchmark, with threading
Remove trailing whitespace
Remove trailing whitespace
ssl_server2: add buffer overhead for a termination character
Add missing large and small packet tests for ssl_server2
Added buffer_size and response_size options for ssl-server2. Added appropriate tests.
Solving a conflict in tests/ssl-opt.sh: two set of tests were added at the
same place (just after large packets):
- restartable ECC tests (in this branch)
- server-side large packets (in development)
Resolution was to move the ECC tests after the newly added server large packet
ones.
* development-restricted: (578 commits)
Update library version number to 2.13.1
Don't define _POSIX_C_SOURCE in header file
Don't declare and define gmtime()-mutex on Windows platforms
Correct preprocessor guards determining use of gmtime()
Correct documentation of mbedtls_platform_gmtime_r()
Correct typo in documentation of mbedtls_platform_gmtime_r()
Correct POSIX version check to determine presence of gmtime_r()
Improve documentation of mbedtls_platform_gmtime_r()
platform_utils.{c/h} -> platform_util.{c/h}
Don't include platform_time.h if !MBEDTLS_HAVE_TIME
Improve wording of documentation of MBEDTLS_PLATFORM_GMTIME_R_ALT
Fix typo in documentation of MBEDTLS_PLATFORM_GMTIME_R_ALT
Replace 'thread safe' by 'thread-safe' in the documentation
Improve documentation of MBEDTLS_HAVE_TIME_DATE
ChangeLog: Add missing renamings gmtime -> gmtime_r
Improve documentation of MBEDTLS_HAVE_TIME_DATE
Minor documentation improvements
Style: Add missing period in documentation in threading.h
Rename mbedtls_platform_gmtime() to mbedtls_platform_gmtime_r()
Guard decl and use of gmtime mutex by HAVE_TIME_DATE and !GMTIME_ALT
...
While these tests and the issue with it are pre-existing:
- we previously didn't understand that the issue was an openssl bug
- failures seem to have become more frequent since the recent changes
So let's disable these fragile tests in order to get a clean CI. We still have
the tests against gnutls-serv for interop testing.
While making the initial commit, I thought $OPENSSL_LEGACY was not affect by
this bug, but it turns out I was wrong. All versions of OpenSSL installed on
the CI are. Therefore, the corresponding tests are disabled for the same
reason as the gnutls-cli tests above it.
This commit is only about the tests that were added in the recent
fragmentation work. One of those two tests had a particularly
annoying mode of failure: it failed consistently with seed=1 (use in the
release version of all.sh), once #1951 was applied. This has nothing
particular to do with #1951, except that by changing retransmission behaviour
1951 made the proxy run into a path that triggered the OpenSSL bug with this
seed, while it previously did that only with other seeds.
Other 3d interop test are also susceptible to triggering this OpenSSL bug or
others (or bugs in GnuTLS), but they are left untouched by this commit as:
- they were pre-existing to the recent DTLS branches;
- they don't seem to have the particularly annoying seed=1 mode of failure.
However it's probably desirable to do something about them at some point in
the future.
This commit adds a test to ssl-opt.sh which exercises the behavior
of the library in the situation where a single proper fragment
of a future handshake message is received prior to the next
expected handshake message (concretely, the client receives
the first fragment of the server's Certificate message prior
to the server's ServerHello).
This commit adds tests to ssl-opt.sh which trigger code-paths
responsible for freeing future buffered messages when the buffering
limitations set by MBEDTLS_SSL_DTLS_MAX_BUFFERING don't allow the
next expected message to be reassembled.
These tests only work for very specific ranges of
MBEDTLS_SSL_DTLS_MAX_BUFFERING and will therefore be skipped
on a run of ssl-opt.sh in ordinary configurations.
This commit adds functions requires_config_value_at_most()
and requires_config_value_at_least() which can be used to
only run tests when a numerical value from config.h
(e.g. MBEDTLS_SSL_IN_CONTENT_LEN) is within a certain range.
The negotiated MFL is always the one suggested by the client, even
if the server has a smaller MFL configured locally. Hence, in the test
where the client asks for an MFL of 4096 bytes while the server locally
has an MFL of 512 bytes configured, the client will still send datagrams
of up to ~4K size.
Depending on the settings of the local machine, gnutls-cli will either try
IPv4 or IPv6 when trying to connect to localhost. With TLS, whatever it tries
first, it will notice if any failure happens and try the other protocol if
necessary. With DTLS it can't do that. Unfortunately for now there isn't
really any good way to specify an address and hostname independently, though
that might come soon: https://gitlab.com/gnutls/gnutls/issues/344
A work around is to specify an address directly and then use --insecure to
ignore certificate hostname mismatch; that is OK for tests that are completely
unrelated to certificate verification (such as the recent fragmenting tests)
but unacceptable for others.
For that reason, don't specify a default hostname for gnutls-cli, but instead
let each test choose between `--insecure 127.0.0.1` and `localhost` (or
`--insecure '::1'` if desired).
Alternatives include:
- having test certificates with 127.0.0.1 as the hostname, but having an IP as
the CN is unusual, and we would need to change our test certs;
- have our server open two sockets under the hood and listen on both IPv4 and
IPv6 (that's what gnutls-serv does, and IMO it's a good thing) but that
obviously requires development and testing (esp. for windows compatibility)
- wait for a newer version of GnuTLS to be released, install it on the CI and
developer machines, and use that in all tests - quite satisfying but can't
be done now (and puts stronger requirements on test environment).
From Hanno:
When a server replies to a cookieless ClientHello with a HelloVerifyRequest,
it is supposed to reset the connection and wait for a subsequent ClientHello
which includes the cookie from the HelloVerifyRequest.
In testing environments, it might happen that the reset of the server
takes longer than for the client to replying to the HelloVerifyRequest
with the ClientHello+Cookie. In this case, the ClientHello gets lost
and the client will need retransmit. This may happen even if the underlying
datagram transport is reliable.
