mbedtls/programs/ssl
Hanno Becker aabbb582eb Exemplify harcoding SSL config at compile-time in example of ExtMS
This commit is the first in a series demonstrating how code-size
can be reduced by hardcoding parts of the SSL configuration at
compile-time, focusing on the example of the configuration of
the ExtendedMasterSecret extension.

The flexibility of an SSL configuration defined a runtime vs.
compile-time is necessary for the use of Mbed TLS as a
dynamically linked library, but is undesirable in constrained
environments because it introduces the following overhead:
- Definition of SSL configuration API (code-size overhead)
  (and on the application-side: The API needs to be called)
- Additional fields in the SSL configuration (RAM overhead,
  and potentially code-size overhead if structures grow
  beyond immediate-offset bounds).
- Dereferencing is needed to obtain configuration settings.
- Code contains branches and potentially additional structure
  fields to distinguish between different configurations.

Considering the example of the ExtendedMasterSecret extension,
this instantiates as follows:
- mbedtls_ssl_conf_extended_master_secret() and
  mbedtls_ssl_conf_extended_master_secret_enforced()
  are introduced to configure the ExtendedMasterSecret extension.
- mbedtls_ssl_config contains bitflags `extended_ms` and
  `enforce_extended_master_secret` reflecting the runtime
  configuration of the ExtendedMasterSecret extension.
- Whenever we need to access these fields, we need a chain
  of dereferences `ssl->conf->extended_ms`.
- Determining whether Client/Server should write the
  ExtendedMasterSecret extension needs a branch
  depending on `extended_ms`, and the state of the
  ExtendedMasterSecret negotiation needs to be stored in a new
  handshake-local variable mbedtls_ssl_handshake_params::extended_ms.
  Finally (that's the point of ExtendedMasterSecret) key derivation
  depends on this handshake-local state of ExtendedMasterSecret.

All this is unnecessary if it is known at compile-time that the
ExtendedMasterSecret extension is used and enforced:
- No API calls are necessary because the configuration is fixed
  at compile-time.
- No SSL config fields are necessary because there are corresponding
  compile-time constants instead.
- Accordingly, no dereferences for field accesses are necessary,
  and these accesses can instead be replaced by the corresponding
  compile-time constants.
- Branches can be eliminated at compile-time because the compiler
  knows the configuration. Also, specifically for the ExtendedMasterSecret
  extension, the field `extended_ms` in the handshake structure
  is unnecessary, because we can fail immediately during the Hello-
  stage of the handshake if the ExtendedMasterSecret extension
  is not negotiated; accordingly, the non-ExtendedMS code-path
  can be eliminated from the key derivation logic.

A way needs to be found to allow fixing parts of the SSL configuration
at compile-time which removes this overhead in case it is used,
while at the same time maintaining readability and backwards
compatibility.

This commit proposes the following approach:

From the user perspective, for aspect of the SSL configuration
mbedtls_ssl_config that should be configurable at compile-time,
introduce a compile-time option MBEDTLS_SSL_CONF_FIELD_NAME.
If this option is not defined, the field is kept and configurable
at runtime as usual. If the option is defined, the field is logically
forced to the value of the option at compile time.

Internally, read-access to fields in the SSL configuration which are
configurable at compile-time gets replaced by new `static inline` getter
functions which evaluate to the corresponding field access or to the
constant MBEDTLS_SSL_CONF_FIELD_NAME, depending on whether the latter
is defined or not.

Write-access to fields which are configurable at compile-time needs
to be removed: Specifically, the corresponding API itself either
needs to be removed or replaced by a stub function without effect.
This commit takes the latter approach, which has the benefit of
not requiring any change on the example applications, but introducing
the risk of mismatching API calls and compile-time configuration,
in case a user doesn't correctly keep track of which parts of the
configuration have been fixed at compile-time, and which haven't.
Write-access for the purpose of setting defaults is simply omitted.
2019-06-25 08:42:20 +01:00
..
CMakeLists.txt Improve cmake inclusion of query_config.c when building apps 2019-02-07 10:32:31 +00:00
dtls_client.c Rename MBEDTLS_X509_INFO to !MBEDTLS_X509_REMOVE_INFO 2019-06-18 11:05:44 +01:00
dtls_server.c Fix const-ness in mbedtls_param_failed() 2018-12-11 12:28:56 +01:00
mini_client.c Fix const-ness in mbedtls_param_failed() 2018-12-11 12:28:56 +01:00
query_config.c Exemplify harcoding SSL config at compile-time in example of ExtMS 2019-06-25 08:42:20 +01:00
ssl_client1.c Merge remote-tracking branch 'origin/pr/591' into baremetal 2019-06-18 17:36:45 +01:00
ssl_client2.c Add missing compile time guard in ssl_client2 2019-06-19 14:59:42 +01:00
ssl_fork_server.c Use negated option for controlling TLS support. 2019-06-17 15:26:34 +02:00
ssl_mail_client.c Merge remote-tracking branch 'origin/pr/591' into baremetal 2019-06-18 17:36:45 +01:00
ssl_pthread_server.c Use negated option for controlling TLS support. 2019-06-17 15:26:34 +02:00
ssl_server2.c Merge remote-tracking branch 'origin/pr/591' into baremetal 2019-06-18 17:36:45 +01:00
ssl_server.c Use negated option for controlling TLS support. 2019-06-17 15:26:34 +02:00