Don't write to the session when computing TLS 1.3 keys
authorBenjamin Kaduk <bkaduk@akamai.com>
Fri, 24 Jan 2020 21:25:53 +0000 (13:25 -0800)
committerBenjamin Kaduk <kaduk@mit.edu>
Fri, 13 Mar 2020 22:55:51 +0000 (15:55 -0700)
commit910c8ffaf83a498667c10a28580dc18cbfd643c5
treef6276c9c26a79822e5bbd1343cfa764c3c82065d
parenta666af9f9df20c466ff5b5554610b5460cf3a362
Don't write to the session when computing TLS 1.3 keys

TLS 1.3 maintains a separate keys chedule in the SSL object, but
was writing to the 'master_key_length' field in the SSL_SESSION
when generating the per-SSL master_secret.  (The generate_master_secret
SSL3_ENC_METHOD function needs an output variable for the master secret
length, but the TLS 1.3 implementation just uses the output size of
the handshake hash function to get the lengths, so the only natural-looking
thing to use as the output length was the field in the session.
This would potentially involve writing to a SSL_SESSION object that was
in the cache (i.e., resumed) and shared with other threads, though.

The thread-safety impact should be minimal, since TLS 1.3 requires the
hash from the original handshake to be associated with the resumption
PSK and used for the subsequent connection.  This means that (in the
resumption case) the value being written would be the same value that was
previously there, so the only risk would be on architectures that can
produce torn writes/reads for aligned size_t values.

Since the value is essentially ignored anyway, just provide the
address of a local dummy variable to generate_master_secret() instead.

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10943)

(cherry picked from commit d74014c4b8740f28a54b562f799ad1e754b517b9)
ssl/statem/statem_lib.c
ssl/statem/statem_srvr.c