This way, it's not required that the label is null-terminated. This
allows us to avoid an allocation in
mbedtls_ssl_tls12_export_keying_material().
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
Previously, if MBEDTLS_SSL_CONTEXT_SERIALIZATION is not defined,
randbytes are not stored after the handshake is done, but they are
needed for TLS-Exporter in TLS 1.2.
This commit also saves randbytes if MBEDTLS_SSL_PROTO_TLS1_2 is defined.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
The length of the generated key must fit into a uint16_t, so it must not
be larger than 0xffff.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
RFC 8446 made it look like we can't use Derive-Secret for the second
step, but actually, Transcript-Hash and Hash are the same thing, so we
can.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
The TLS-Exporter is a function to derive shared symmetric keys for the
server and client from the secrets generated during the handshake.
It is defined in RFC 8446, Section 7.5 for TLS 1.3 and in RFC 5705 for
TLS 1.2.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
We were not making enough room. We want to move everything from the
place where we are going to insert the new record.
This was not causing failures because the code does not look at the
content after the inserted record, because it correctly returns an error
when seeing the inserted record. But as a matter on principle, the test
code should be doing what it says: just insert a new record but leave
a valid fragment after it.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This one is overly tight: TLS 1.3 actually only depends on
ChachaPoly || (AES && (GCM || CCM))
Furthermore, this should really be reflected in check_config.h.
Individual test cases should be able to just request PROTO_TLS1_3 and
know that there is ciphersuite that works.
However, resolving that seems out of scope for this PR. (It would also
involve updating depends.py for example.)
So, use a dependency that's stricted than necessary. IMO it's still good
enough as most configs we test will have ChachaPoly. However it would be
good to revisit this when a cleaner solution is implemented.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The function depends on MBEDTLS_SSL_HANDSHAKE_WITH_CERT_ENABLED which is
basically
MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_EPHEMERAL_ENABLED ||
MBEDTLS_KEY_EXCHANGE_WITH_CERT_ENABLED
The individual test cases depend on the specific TLS version.
This is not precise enough. In a build with both TLS versions enabled,
we could have cert-based key exchange in one version but not in the
other. So, we need the 1.3 tests to depend on the 1.3 cert-based key
exchange and similarly for 1.2.
For 1.2, cert-based key exchange means ECDHE-{RSA,ECDSA} or
ECDH-{RSA,ECDSA}. Since the test function sets an ECC cert for the
server, we want one of the ECDSA ones. So, the minimal dependency would
be ECDH_ECDSA || ECDHE_ECDSA. Since dependencies with || are
inconvenient to express, and anyway ECDH_ECDSA (static ECDH) is
something we'd like to remove in 4.0 if we can find the time, I chose to
just depend on ECDHE_ECDSA.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
These are not optimal. For example, the tests should in principle be
able to run in builds without ECDSA, by using RSA certs instead. Ideally
PSK should work too.
However, getting optimal dependencies would be a lot of work that's
largely orthogonal to the purpose of this PR, so we'll settle for good
enough.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Simulate the server closing the connection after a partial handshake
message.
These test cases don't send a close_notify alert. The test cases
"insert alert record" exercise what happens if the server sends an alert.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Create tests that coalesce the handshake messages in the first flight from
the server. This lets us test the behavior of the library when a handshake
record contains multiple handshake messages.
Only non-protected (non-encrypted, non-authenticated) handshake messages are
supported.
The test code works for all protocol versions, but it is only effective in
TLS 1.2. In TLS 1.3, there is only a single non-encrypted handshake record,
so we can't test records containing more than one handshake message without
a lot more work.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
