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>
See the comments in the code for how an attack would go, and the ChangeLog
entry for an impact assessment. (For ECDSA, leaking a few bits of the scalar
over several signatures translates to full private key recovery using a
lattice attack.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Document that git is needed.
Be clearer about the entry sort key being an entry sort key, not just
a merge order. Be clearer about what "merge order" means.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This change was first introduced in 8af3923 - see this commit for more background.
After the removal of crypto directory, there are no targets that require a
crypto library with the directory prefix, so there's also no need for the priority
dependency to be declared. This commit removes it.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Changelog entry files were listed in reverse alphabetical order of the
file name, by happenstance. Now, changelog entry files are listed in
the order in which the changes were merged. More precisely: look for
the git commit where the entry file was created, and look where this
commit was merged into the current branch. List older merges first.
List never-merged commits in date order after all the merged ones.
List never-committed files in file timestamp order after all the
committed ones.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
All the content that is currently in ChangeLog.md is the result of
merging Mbed Crypto, and that content is already present in
ChangeLog. Since we aren't using ChangeLog.md yet, remove it for now.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Conflicts:
* .github/issue_template.md, .github/pull_request_template.md:
The changes in Mbed Crypto are not relevant to Mbed TLS. Keep the
mbedtls versions.
Pylint warns about things like ``log.info('...'.format(...))``.
It insists on ``log.info('...', ...)``.
This is of minor utility (mainly a performance gain when there are
many messages that use formatting and are below the log level).
Some versions of Pylint (including 1.8, which is the version on
Ubuntu 18.04) only recognize old-style format strings using '%',
and complain about something like ``log.info('{}', foo)`` with
logging-too-many-args (Pylint supports new-style formatting if
declared globally with logging_format_style under [LOGGING] but
this requires Pylint >=2.2).
Disable this warning to remain compatible with Pylint 1.8 and not have
to change abi_check.py to use %-formats instead of {}-formats when
logging.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Rather than sometimes returning an integer, sometimes a boolean and
sometimes implicitly returning None, always return 0 for success and 1
for failure.
No behavior change for the program as a whole, since the None/True/False
values were implicitly converted to the desired numerical value.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't use a function argument as a for loop variable. It worked (mostly) but
Pylint frowns on it (redefined-argument-from-local) and I think Pylint has a
point.
If the configuration file is not found, raise an exception mentioning the
search path rather than just its last element.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
