Restore historical behavior for absent ServerHello extensions
authorBenjamin Kaduk <bkaduk@akamai.com>
Wed, 30 Aug 2017 19:57:27 +0000 (14:57 -0500)
committerBenjamin Kaduk <kaduk@mit.edu>
Thu, 7 Sep 2017 14:53:21 +0000 (09:53 -0500)
commit1c259bb51824a2e3da990c76dd49e5dcaed334ea
tree3f9e3b2635249f22f54818fa3e178d3c76819e45
parentd3c3dfc5778ab2cca0d25c5959c8b814a334addb
Restore historical behavior for absent ServerHello extensions

In OpenSSL 1.1.0, when there were no extensions added to the ServerHello,
we did not write the extension data length bytes to the end of the
ServerHello; this is needed for compatibility with old client implementations
that do not support TLS extensions (such as the default configuration of
OpenSSL 0.9.8).  When ServerHello extension construction was converted
to the new extensions framework in commit
7da160b0f46d832dbf285cb0b48ae56d4a8b884d, this behavior was inadvertently
limited to cases when SSLv3 was negotiated (and similarly for ClientHellos),
presumably since extensions are not defined at all for SSLv3.  However,
extensions for TLS prior to TLS 1.3 have been defined in separate
RFCs (6066, 4366, and 3546) from the TLS protocol specifications, and as such
should be considered an optional protocol feature in those cases.

Accordingly, be conservative in what we send, and skip the extensions block
when there are no extensions to be sent, regardless of the TLS/SSL version.
(TLS 1.3 requires extensions and can safely be treated differently.)

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4296)
ssl/statem/extensions.c