mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-12-15 06:01:37 +08:00
Code Issues Packages Projects Releases Wiki Activity
f984323fcd
openssl/test/ssl-tests/06-sni-ticket.cnf

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

768 lines
19 KiB
Plaintext
Raw Normal View History

Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# Generated with generate_ssl_tests.pl
num_tests = 17
test-0 = 0-sni-session-ticket
test-1 = 1-sni-session-ticket
test-2 = 2-sni-session-ticket
test-3 = 3-sni-session-ticket
test-4 = 4-sni-session-ticket
test-5 = 5-sni-session-ticket
test-6 = 6-sni-session-ticket
test-7 = 7-sni-session-ticket
test-8 = 8-sni-session-ticket
test-9 = 9-sni-session-ticket
test-10 = 10-sni-session-ticket
test-11 = 11-sni-session-ticket
test-12 = 12-sni-session-ticket
test-13 = 13-sni-session-ticket
test-14 = 14-sni-session-ticket
test-15 = 15-sni-session-ticket
test-16 = 16-sni-session-ticket
# ===========================================================
[0-sni-session-ticket]
ssl_conf = 0-sni-session-ticket-ssl
[0-sni-session-ticket-ssl]
server = 0-sni-session-ticket-server
client = 0-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 0-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[0-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[0-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[0-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-0]
ExpectedResult = Success
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
SessionTicketExpected = No
server = 0-sni-session-ticket-server-extra
client = 0-sni-session-ticket-client-extra
[0-sni-session-ticket-server-extra]
BrokenSessionTicket = Yes
[0-sni-session-ticket-client-extra]
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
ServerName = server1
# ===========================================================
[1-sni-session-ticket]
ssl_conf = 1-sni-session-ticket-ssl
[1-sni-session-ticket-ssl]
server = 1-sni-session-ticket-server
client = 1-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 1-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[1-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[1-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[1-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-1]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server1
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = Yes
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 1-sni-session-ticket-server-extra
client = 1-sni-session-ticket-client-extra
[1-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[1-sni-session-ticket-client-extra]
ServerName = server1
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[2-sni-session-ticket]
ssl_conf = 2-sni-session-ticket-ssl
[2-sni-session-ticket-ssl]
server = 2-sni-session-ticket-server
client = 2-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 2-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[2-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[2-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[2-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-2]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server2
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = Yes
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 2-sni-session-ticket-server-extra
client = 2-sni-session-ticket-client-extra
[2-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[2-sni-session-ticket-client-extra]
ServerName = server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[3-sni-session-ticket]
ssl_conf = 3-sni-session-ticket-ssl
[3-sni-session-ticket-ssl]
server = 3-sni-session-ticket-server
client = 3-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 3-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[3-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[3-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[3-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-3]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server1
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = Yes
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 3-sni-session-ticket-server-extra
client = 3-sni-session-ticket-client-extra
[3-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[3-sni-session-ticket-client-extra]
ServerName = server1
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[4-sni-session-ticket]
ssl_conf = 4-sni-session-ticket-ssl
[4-sni-session-ticket-ssl]
server = 4-sni-session-ticket-server
client = 4-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 4-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[4-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[4-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[4-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-4]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server2
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 4-sni-session-ticket-server-extra
client = 4-sni-session-ticket-client-extra
[4-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[4-sni-session-ticket-client-extra]
ServerName = server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[5-sni-session-ticket]
ssl_conf = 5-sni-session-ticket-ssl
[5-sni-session-ticket-ssl]
server = 5-sni-session-ticket-server
client = 5-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 5-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[5-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[5-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[5-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-5]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server1
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 5-sni-session-ticket-server-extra
client = 5-sni-session-ticket-client-extra
[5-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[5-sni-session-ticket-client-extra]
ServerName = server1
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[6-sni-session-ticket]
ssl_conf = 6-sni-session-ticket-ssl
[6-sni-session-ticket-ssl]
server = 6-sni-session-ticket-server
client = 6-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 6-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[6-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[6-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[6-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-6]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server2
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 6-sni-session-ticket-server-extra
client = 6-sni-session-ticket-client-extra
[6-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[6-sni-session-ticket-client-extra]
ServerName = server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[7-sni-session-ticket]
ssl_conf = 7-sni-session-ticket-ssl
[7-sni-session-ticket-ssl]
server = 7-sni-session-ticket-server
client = 7-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 7-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[7-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[7-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[7-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-7]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server1
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 7-sni-session-ticket-server-extra
client = 7-sni-session-ticket-client-extra
[7-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[7-sni-session-ticket-client-extra]
ServerName = server1
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[8-sni-session-ticket]
ssl_conf = 8-sni-session-ticket-ssl
[8-sni-session-ticket-ssl]
server = 8-sni-session-ticket-server
client = 8-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 8-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[8-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[8-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[8-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-8]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server2
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 8-sni-session-ticket-server-extra
client = 8-sni-session-ticket-client-extra
[8-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[8-sni-session-ticket-client-extra]
ServerName = server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[9-sni-session-ticket]
ssl_conf = 9-sni-session-ticket-ssl
[9-sni-session-ticket-ssl]
server = 9-sni-session-ticket-server
client = 9-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 9-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[9-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[9-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[9-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = -SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-9]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server1
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 9-sni-session-ticket-server-extra
client = 9-sni-session-ticket-client-extra
[9-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[9-sni-session-ticket-client-extra]
ServerName = server1
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[10-sni-session-ticket]
ssl_conf = 10-sni-session-ticket-ssl
[10-sni-session-ticket-ssl]
server = 10-sni-session-ticket-server
client = 10-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 10-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[10-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[10-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[10-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = -SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-10]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server2
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 10-sni-session-ticket-server-extra
client = 10-sni-session-ticket-client-extra
[10-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[10-sni-session-ticket-client-extra]
ServerName = server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[11-sni-session-ticket]
ssl_conf = 11-sni-session-ticket-ssl
[11-sni-session-ticket-ssl]
server = 11-sni-session-ticket-server
client = 11-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 11-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[11-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[11-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[11-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = -SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-11]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server1
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 11-sni-session-ticket-server-extra
client = 11-sni-session-ticket-client-extra
[11-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[11-sni-session-ticket-client-extra]
ServerName = server1
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[12-sni-session-ticket]
ssl_conf = 12-sni-session-ticket-ssl
[12-sni-session-ticket-ssl]
server = 12-sni-session-ticket-server
client = 12-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 12-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[12-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[12-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[12-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = -SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-12]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server2
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 12-sni-session-ticket-server-extra
client = 12-sni-session-ticket-client-extra
[12-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[12-sni-session-ticket-client-extra]
ServerName = server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[13-sni-session-ticket]
ssl_conf = 13-sni-session-ticket-ssl
[13-sni-session-ticket-ssl]
server = 13-sni-session-ticket-server
client = 13-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 13-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[13-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[13-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[13-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = -SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-13]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server1
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 13-sni-session-ticket-server-extra
client = 13-sni-session-ticket-client-extra
[13-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[13-sni-session-ticket-client-extra]
ServerName = server1
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[14-sni-session-ticket]
ssl_conf = 14-sni-session-ticket-ssl
[14-sni-session-ticket-ssl]
server = 14-sni-session-ticket-server
client = 14-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 14-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[14-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[14-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[14-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = -SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-14]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server2
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 14-sni-session-ticket-server-extra
client = 14-sni-session-ticket-client-extra
[14-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[14-sni-session-ticket-client-extra]
ServerName = server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[15-sni-session-ticket]
ssl_conf = 15-sni-session-ticket-ssl
[15-sni-session-ticket-ssl]
server = 15-sni-session-ticket-server
client = 15-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 15-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[15-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[15-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[15-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = -SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-15]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server1
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 15-sni-session-ticket-server-extra
client = 15-sni-session-ticket-client-extra
[15-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[15-sni-session-ticket-client-extra]
ServerName = server1
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
# ===========================================================
[16-sni-session-ticket]
ssl_conf = 16-sni-session-ticket-ssl
[16-sni-session-ticket-ssl]
server = 16-sni-session-ticket-server
client = 16-sni-session-ticket-client
SSL tests: compress generated output a little Don't emit duplicate server/client sections when they are identical. Instead, just point to the same section. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-22 01:19:07 +08:00
server2 = 16-sni-session-ticket-server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
[16-sni-session-ticket-server]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[16-sni-session-ticket-server2]
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
CipherString = DEFAULT
Options = -SessionTicket
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
[16-sni-session-ticket-client]
CipherString = DEFAULT
Remove old style NewSessionTicket from TLSv1.3 TLSv1.3 has a NewSessionTicket message, but it is *completely* different to the TLSv1.2 one and may as well have been called something else. This commit removes the old style NewSessionTicket from TLSv1.3. We will have to add the new style one back in later. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-09 00:10:21 +08:00
MaxProtocol = TLSv1.2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Options = -SessionTicket
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
VerifyMode = Peer
[test-16]
ExpectedResult = Success
SSL test framework: port SNI tests Observe that the old tests were partly ill-defined: setting sn_server1 but not sn_server2 in ssltest_old.c does not enable the SNI callback. Fix this, and also explicitly test both flavours of SNI mismatch (ignore / fatal alert). Tests still pass. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-06-20 23:20:25 +08:00
ExpectedServerName = server2
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)
2016-09-01 20:40:54 +08:00
SessionIdExpected = Yes
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
SessionTicketExpected = No
Reorganize SSL test structures Move custom server and client options from the test dictionary to an "extra" section of each server/client. Rename test expectations to say "Expected". This is a big but straightforward change. Primarily, this allows us to specify multiple server and client contexts without redefining the custom options for each of them. For example, instead of "ServerNPNProtocols", "Server2NPNProtocols", "ResumeServerNPNProtocols", we now have, "NPNProtocols". This simplifies writing resumption and SNI tests. The first application will be resumption tests for NPN and ALPN. Regrouping the options also makes it clearer which options apply to the server, which apply to the client, which configure the test, and which are test expectations. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-21 22:29:48 +08:00
server = 16-sni-session-ticket-server-extra
client = 16-sni-session-ticket-client-extra
[16-sni-session-ticket-server-extra]
ServerNameCallback = IgnoreMismatch
[16-sni-session-ticket-client-extra]
ServerName = server2
Fix session ticket and SNI When session tickets are used, it's possible that SNI might swtich the SSL_CTX on an SSL. Normally, this is not a problem, because the initial_ctx/session_ctx are used for all session ticket/id processes. However, when the SNI callback occurs, it's possible that the callback may update the options in the SSL from the SSL_CTX, and this could cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things can happen: 1. The session ticket TLSEXT may not be written when the ticket expected flag is set. The state machine transistions to writing the ticket, and the client responds with an error as its not expecting a ticket. 2. When creating the session ticket, if the ticket key cb returns 0 the crypto/hmac contexts are not initialized, and the code crashes when trying to encrypt the session ticket. To fix 1, if the ticket TLSEXT is not written out, clear the expected ticket flag. To fix 2, consider a return of 0 from the ticket key cb a recoverable error, and write a 0 length ticket and continue. The client-side code can explicitly handle this case. Fix these two cases, and add unit test code to validate ticket behavior. Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1098)
2016-05-13 06:16:52 +08:00
Reference in New Issue Copy Permalink