tree 8b93d7b5985feec2f2cf257c141a16127d593566
parent ac6cc9fbc493b2f9fece3e00a0066852a9b368f2
author Hanno Becker <hanno.becker@arm.com> 1627017948 +0100
committer Hanno Becker <hanno.becker@arm.com> 1627017948 +0100

Store TLS version in SSL session structure

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>