• B
    Fix a race condition in SNI handling · 328fd883
    Benjamin Kaduk 提交于
    As was done for ciphers, supported groups, and EC point formats in
    https://github.com/openssl/openssl/pull/9162, only write the negotiated
    SNI hostname value to the session object when not resuming, even for
    TLS 1.3 resumptions.  Otherwise, when using a stateful session cache
    (as is done by default when 0-RTT data is enabled), we can have multiple
    SSLs active using the same in-memory session object, which leads to
    double-frees and similar race conditions in the SNI handler prior
    to this commit.
    
    Fortunately, since draft-ietf-tls-tls13-22, there is no requirement
    that the SNI hostname be preserved across TLS 1.3 resumption, and thus
    not a need to continually update the session object with the "current"
    value (to be used when producing session tickets, so that the subsequent
    resumption can be checked against the current value).  So we can just
    relax the logic and only write to the session object for initial handshakes.
    This still leaves us in a somewhat inconsistent state, since if the SNI value
    does change across handshakes, the session object will continue to record
    the initial handshake's value, even if that bears no relation to the
    current handshake.  The current SSL_get_servername() implementation
    prefers the value from the session if s->hit, but a more complete fix
    for that and related issues is underway in
    https://github.com/openssl/openssl/pull/10018; there is no need to wait
    for the complete fix for SNI name handling in order to close the
    race condition and avoid runtime crashes.
    Reviewed-by: NMatt Caswell <matt@openssl.org>
    (Merged from https://github.com/openssl/openssl/pull/10441)
    
    (cherry picked from commit 2a5385511051d33be8d2b20d7669d8b1862fe510)
    328fd883
extensions.c 59.5 KB