Code to thread-safety in ChangeCipherState
authorBenjamin Kaduk <bkaduk@akamai.com>
Fri, 24 Jan 2020 21:44:27 +0000 (13:44 -0800)
committerBenjamin Kaduk <kaduk@mit.edu>
Fri, 13 Mar 2020 21:20:14 +0000 (14:20 -0700)
commit2e3ec2e1578977fca830a47fd7f521e290540e6d
treeeefd4e2c6d1c13fb2615a8fe057bc9aabe60f953
parentd74014c4b8740f28a54b562f799ad1e754b517b9
Code to thread-safety in ChangeCipherState

The server-side ChangeCipherState processing stores the new cipher
in the SSL_SESSION object, so that the new state can be used if
this session gets resumed.  However, writing to the session is only
thread-safe for initial handshakes, as at other times the session
object may be in a shared cache and in use by another thread at the
same time.  Reflect this invariant in the code by only writing to
s->session->cipher when it is currently NULL (we do not cache sessions
with no cipher).  The code prior to this change would never actually
change the (non-NULL) cipher value in a session object, since our
server enforces that (pre-TLS-1.3) resumptions use the exact same
cipher as the initial connection, and non-abbreviated renegotiations
have produced a new session object before we get to this point.
Regardless, include logic to detect such a condition and abort the
handshake if it occurs, to avoid any risk of inadvertently using
the wrong cipher on a connection.

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10943)
crypto/err/openssl.txt
include/openssl/sslerr.h
ssl/statem/statem_srvr.c