The "full" configuration excludes some deprecated or experimental
features. Enable the ones that have tests, don't have extra
requirements and don't turn off some other feature.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The seedfile needs to have the size of the entropy accumulator, which
is 64 bytes (512 bits) since the entropy accumulator uses SHA-512 and
the seed size needs to be the same as the hash output (or larger).
We used to enable MBEDTLS_ENTROPY_FORCE_SHA256 in the full config, so
the entropy accumulator was 256 bits (32 bytes), and therefore a
32-byte seedfile worked. But we no longer turn on this option in the
full config, so the 32-byte seedfile no longer works.
Signed-off-by: Gilles Peskine <Gilles.Peskine@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>
t is never used uninitialized, since the first loop iteration reads 0
bytes of it and then writes hash_len bytes, and subsequent iterations
read and write hash_len bytes. However this is somewhat fragile, and
it would be legitimate for a static analyzer to be unsure.
Initialize t explicitly, to make the code clearer and more robust, at
negligible cost.
Reported by Vasily Evseenko in
https://github.com/ARMmbed/mbedtls/pull/2942
with a slightly different fix.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Adding .function was necessary, as otherwise ctags would have no idea what to
do with those files.
Adding .h may not be necessary, as by default ctags considers them C++ which
is probably good enough, but since we're tuning the mapping anyway...
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Update issue template to direct questions to the TrustedFirmware.org
mailing list instead of using the GitHub issue tracker.
Signed-off-by: Dan Handley <dan.handley@arm.com>
Previously, doxygen was unable to effectively use preprocessing to determine
which parts of code should be documented. This was due to its inability to
include headers during preprocessing, which was discovered by running it in
preprocessing debug mode:
doxygen -d preprocessor mbedtls.doxyfile
An example of failure: "#include mbedtls/config.h: not found! skipping..."
With the following fix includes are properly preprocessed with the documentation
being considerably larger.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
The current logging was sub-standard, in particular there was no trace
whatsoever of the HelloVerifyRequest being sent. Now it's being logged with
the usual levels: 4 for full content, 2 return of f_send, 1 decision about
sending it (or taking other branches in the same function) because that's the
same level as state changes in the handshake, and also same as the "possible
client reconnect" message" to which it's the logical continuation (what are we
doing about it?).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Fix an intermittent crash when running test suites in non-verbose
mode (i.e. with -v off) and with the outcome file enabled. The
array unmet_dependencies was only filled in verbose mode, but was used
in write_outcome_result regardless.
Since unmet_dependencies only ever contains strings that are integers
written out in decimal, store the integer instead. Do this
unconditionally since it doesn't cost any extra memory.
It would be better to record the dependency names, both in the verbose
output and in the outcome file. But the dependency names are not
currently available at runtime.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Instead of working with Markdown format, keep the classic Mbed TLS
ChangeLog format, with the classic category names. Keep the classic
file name as well. This way there's no risk of breaking third-party
scripts that may copy or even parse the changelog file.
Accordingly, expect ChangeLog/*.txt files instead of ChangeLog/*.md.
This commit completely rewrites the parsing and output code.
This commit systematically appends to the existing top version. A
subsequent commit will restore the capability of creating a new
version.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In x509.c, the self-test code is dependent on MBEDTLS_CERTS_C and
MBEDTLS_SHA256_C being enabled. At some point in the recent past that dependency
was on MBEDTLS_SHA1_C but changed to SHA256, but the comment wasn't updated.
This commit updates the comment.
Signed-off-by: Simon Butcher <simon.butcher@arm.com>
Additional sanity checks in check_config.h to ensure:
* if test certificates are included (MBEDTLS_CERTS_C) there must be also be
support for the core X509 feature (MBEDTLS_X509_USE_C). This has a
secondary dependency on the public key abstraction layer (MBEDTLS_PK_C),
necessary as the certificates will either be signed by RSA or ECDSA, and
therefore need to be part of the library.
* if any of the TLS protocols are defined (MBEDTLS_SSL_PROTO_xxx) then a
key exchange method must also be defined (MBEDTLS_KEY_EXCHANGE_xxx).
Anyone who knows the library will probably not make these mistakes or will
quickly diagnose and fix them, but it is possible to compile and link both
configurations if you build only the library and not the example programs, and
therefore users may not realise immediately that there's a mistake, only
discovering it at runtime.
These checks may therefore save someone some time.
Signed-off-by: Simon Butcher <simon.butcher@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>
Section 4.2.8 of RFC 6347 describes how to handle the case of a DTLS client
establishing a new connection using the same UDP quartet as an already active
connection, which we implement under the compile option
MBEDTLS_SSL_DLTS_CLIENT_PORT_REUSE. Relevant excerpts:
[the server] MUST NOT destroy the existing
association until the client has demonstrated reachability either by
completing a cookie exchange or by completing a complete handshake
including delivering a verifiable Finished message.
[...]
The reachability requirement prevents
off-path/blind attackers from destroying associations merely by
sending forged ClientHellos.
Our code chooses to use a cookie exchange for establishing reachability, but
unfortunately that check was effectively removed in a recent refactoring,
which changed what value ssl_handle_possible_reconnect() needs to return in
order for ssl_get_next_record() (introduced in that refactoring) to take the
proper action. Unfortunately, in addition to changing the value, the
refactoring also changed a return statement to an assignment to the ret
variable, causing the function to reach the code for a valid cookie, which
immediately destroys the existing association, effectively bypassing the
cookie verification.
This commit fixes that by immediately returning after sending a
HelloVerifyRequest when a ClientHello without a valid cookie is found. It also
updates the description of the function to reflect the new return value
convention (the refactoring updated the code but not the documentation).
The commit that changed the return value convention (and introduced the bug)
is 2fddd3765e, whose commit message explains the
change.
Note: this bug also indirectly caused the ssl-opt.sh test case "DTLS client
reconnect from same port: reconnect" to occasionally fail due to a race
condition between the reception of the ClientHello carrying a valid cookie and
the closure of the connection by the server after noticing the ClientHello
didn't carry a valid cookie after it incorrectly destroyed the previous
connection, that could cause that ClientHello to be invisible to the server
(if that message reaches the server just before it does `net_close()`). A
welcome side effect of this commit is to remove that race condition, as the
new connection will immediately start with a ClientHello carrying a valid
cookie in the SSL input buffer, so the server will not call `net_close()` and
not risk discarding a better ClientHello that arrived in the meantime.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
