Instances of `mbedtls_ssl_session` represent data enabling session resumption.
With the introduction of TLS 1.3, the format of this data changes. We therefore
need TLS-version field as part of `mbedtlsl_ssl_session` which allows distinguish
1.2 and 1.3 sessions.
This commit introduces such a TLS-version field to mbedtls_ssl_session.
The change has a few ramifications:
- Session serialization/deserialization routines need to be adjusted.
This is achieved by adding the TLS-version after the header of
Mbed TLS version+config, and by having the subsequent structure
of the serialized data depend on the value of this field.
The details are described in terms of the RFC 8446 presentation language.
The 1.2 session (de)serialization are moved into static helper functions,
while the top-level session (de)serialization only parses the Mbed TLS
version+config header and the TLS-version field, and dispatches according
to the found version.
This way, it will be easy to add support for TLS 1.3 sessions in the future.
- Tests for session serialization need to be adjusted
- Once we add support for TLS 1.3, with runtime negotiation of 1.2 vs. 1.3,
we will need to have some logic comparing the TLS version of the proposed session
to the negotiated TLS version. For now, however, we only support TLS 1.2,
and no such logic is needed. Instead, we just store the TLS version in the
session structure at the same point when we populate mbedtls_ssl_context.minor_ver.
The change introduces some overlap between `mbedtls_ssl_session.minor_ver` and
`mbedtls_ssl_context.minor_ver`, which should be studied and potentially resolved.
However, with both fields being private and explicitly marked so, this can happen
in a later change.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Previous code checked that the buffer was big enough for the tag size
for the given algorithm, however chachapoly finish expects a 16 byte
buffer passed in, no matter what. If we start supporting smaller
chachapoly tags in the future, this could potentially end up in buffer
overflow, so add a safety check.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Previous test in state test was not actually making sure that the
operatioon could be completed using set lengths / set nonce in either
order, thus changed the 'normal' encrypt / decrypt tests to run in
alternating order.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Make all encrypt/decrypt tests use the same function. Cleanup arguments
that were poorly named and document internal function. Removed one test
as I didn't want to write another test purely for it, when its already
tested in one shot.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
The previous implementation was hard to understand and could in principle
fail to notice if there was a test case failure and the writing of the
line "Note: $TOTAL_FAIL failures." failed. KISS.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The internal verify endpoint was only calling the finish endpoint to get
a tag to compare against the tag passed in. Moved this logic to the
driver wrapper (still allowing a driver to call verify if required) and
removed the internal implementation endpoint.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
We already did this on failure, but make sure the buffer does not leak
what was in it previously on success
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
What matters is that we validate that test data is not removed. Keeping the
test data is the most obvious way, but not the only way.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The import-and-save and load-and-check parts of the tests don't have to be
actually the same test cases.
Introduce the terms “forward compatibility” and “backward compatibility” and
relate them to import-and-save and load-and-check actions.
These are clarifications of intent that do not represent an intended change
in the strategy or intended coverage.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
