Reuse extension_is_relevant() in should_add_extension()
authorBenjamin Kaduk <bkaduk@akamai.com>
Tue, 14 Mar 2017 19:41:08 +0000 (14:41 -0500)
committerBen Kaduk <kaduk@mit.edu>
Fri, 9 Mar 2018 17:17:32 +0000 (11:17 -0600)
commitee36b963aef8dc18d2016970d808a7287e6d38fc
tree624338c5471608f82e2def7f678e24a028e9f8a3
parentb0143b97529959470c90df157368c2925180e3c3
Reuse extension_is_relevant() in should_add_extension()

At the core of things is the concept that each extension is only
defined in certain context(s) -- the ClientHello, EncryptedExtensions,
etc., and sometimes only for a specific protocol or protocol range;
we want to enforce that we only parse or generate extensions in the
context(s) for which they are defined.  There is some subtlety here,
in that the protocol version in use is not known when generating the
ClientHello (but it is known when the ClientHello extensions are
being parsed!), so the SSL_IS_TLS13() macro must be used with caution.
Nonetheless, by making assertions about whether we are acting in a
server role and whether the current context is (not) a ClientHello,
we can consolidate almost all of the logic for determining whether
an extension is permitted in a given protocol message, whether we
are generating or parsing that message.

The only logic that remains separate relates to generating the ClientHello,
as it depends on an external factor (the maximum permitted TLS version) that
is not defined in the parsing context.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2945)
ssl/statem/extensions.c