Session resume broken switching contexts
When an SSL's context is swtiched from a ticket-enabled context to
a ticket-disabled context in the servername callback, no session-id
is generated, so the session can't be resumed.
If a servername callback changes the SSL_OP_NO_TICKET option, check
to see if it's changed to disable, and whether a session ticket is
expected (i.e. the client indicated ticket support and the SSL had
tickets enabled at the time), and whether we already have a previous
session (i.e. s->hit is set).
In this case, clear the ticket-expected flag, remove any ticket data
and generate a session-id in the session.
If the SSL hit (resumed) and switched to a ticket-disabled context,
assume that the resumption was via session-id, and don't bother to
update the session.
Before this fix, the updated unit-tests in 06-sni-ticket.conf would
fail test #4 (server1 = SNI, server2 = no SNI).
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/1529)
diff --git a/test/README.ssltest.md b/test/README.ssltest.md
index c4540b4..3b4bb56 100644
--- a/test/README.ssltest.md
+++ b/test/README.ssltest.md
@@ -81,6 +81,11 @@
- Yes - a session ticket is expected
- No - a session ticket is not expected
+* SessionIdExpected - whether or not a session id is expected
+ - Ignore - do not check for a session id (default)
+ - Yes - a session id is expected
+ - No - a session id is not expected
+
* ResumptionExpected - whether or not resumption is expected (Resume mode only)
- Yes - resumed handshake
- No - full handshake (default)
