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 23:11:45 +0000 (16:11 -0700)
commit44bad9cbf7daa5ff7dd201e0c61e684b2e2eb971
tree7566571c3c79cf9b78b08a2a59362e178759e651
parent910c8ffaf83a498667c10a28580dc18cbfd643c5
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)

(cherry picked from commit 2e3ec2e1578977fca830a47fd7f521e290540e6d)
crypto/err/openssl.txt
include/openssl/sslerr.h
ssl/statem/statem_srvr.c