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
|
|
|
|
|
2016-06-20 23:20:25 +08:00
|
|
|
num_tests = 6
|
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
|
|
|
|
2016-06-20 23:20:25 +08:00
|
|
|
test-0 = 0-SNI-switch-context
|
|
|
|
test-1 = 1-SNI-keep-context
|
|
|
|
test-2 = 2-SNI-no-server-support
|
|
|
|
test-3 = 3-SNI-no-client-support
|
|
|
|
test-4 = 4-SNI-bad-sni-ignore-mismatch
|
|
|
|
test-5 = 5-SNI-bad-sni-reject-mismatch
|
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
|
|
|
# ===========================================================
|
|
|
|
|
2016-06-20 23:20:25 +08:00
|
|
|
[0-SNI-switch-context]
|
|
|
|
ssl_conf = 0-SNI-switch-context-ssl
|
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
|
|
|
|
2016-06-20 23:20:25 +08:00
|
|
|
[0-SNI-switch-context-ssl]
|
|
|
|
server = 0-SNI-switch-context-server
|
|
|
|
client = 0-SNI-switch-context-client
|
2016-07-22 01:19:07 +08:00
|
|
|
server2 = 0-SNI-switch-context-server
|
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
|
|
|
|
2016-06-20 23:20:25 +08:00
|
|
|
[0-SNI-switch-context-server]
|
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
|
|
|
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
|
|
|
|
CipherString = DEFAULT
|
|
|
|
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
|
|
|
|
|
2016-06-20 23:20:25 +08:00
|
|
|
[0-SNI-switch-context-client]
|
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
|
|
|
CipherString = DEFAULT
|
|
|
|
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
|
|
|
|
VerifyMode = Peer
|
|
|
|
|
|
|
|
[test-0]
|
|
|
|
ExpectedResult = Success
|
2016-06-20 23:20:25 +08:00
|
|
|
ExpectedServerName = server2
|
2016-07-21 22:29:48 +08:00
|
|
|
server = 0-SNI-switch-context-server-extra
|
|
|
|
server2 = 0-SNI-switch-context-server-extra
|
|
|
|
client = 0-SNI-switch-context-client-extra
|
|
|
|
|
|
|
|
[0-SNI-switch-context-server-extra]
|
2016-06-20 23:20:25 +08:00
|
|
|
ServerNameCallback = IgnoreMismatch
|
|
|
|
|
2016-07-21 22:29:48 +08:00
|
|
|
[0-SNI-switch-context-client-extra]
|
|
|
|
ServerName = server2
|
|
|
|
|
2016-06-20 23:20:25 +08:00
|
|
|
|
|
|
|
# ===========================================================
|
|
|
|
|
|
|
|
[1-SNI-keep-context]
|
|
|
|
ssl_conf = 1-SNI-keep-context-ssl
|
|
|
|
|
|
|
|
[1-SNI-keep-context-ssl]
|
|
|
|
server = 1-SNI-keep-context-server
|
|
|
|
client = 1-SNI-keep-context-client
|
2016-07-22 01:19:07 +08:00
|
|
|
server2 = 1-SNI-keep-context-server
|
2016-06-20 23:20:25 +08:00
|
|
|
|
|
|
|
[1-SNI-keep-context-server]
|
|
|
|
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
|
|
|
|
CipherString = DEFAULT
|
|
|
|
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
|
|
|
|
|
|
|
|
[1-SNI-keep-context-client]
|
|
|
|
CipherString = DEFAULT
|
|
|
|
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
|
|
|
|
VerifyMode = Peer
|
|
|
|
|
|
|
|
[test-1]
|
|
|
|
ExpectedResult = Success
|
|
|
|
ExpectedServerName = server1
|
2016-07-21 22:29:48 +08:00
|
|
|
server = 1-SNI-keep-context-server-extra
|
|
|
|
server2 = 1-SNI-keep-context-server-extra
|
|
|
|
client = 1-SNI-keep-context-client-extra
|
|
|
|
|
|
|
|
[1-SNI-keep-context-server-extra]
|
2016-06-20 23:20:25 +08:00
|
|
|
ServerNameCallback = IgnoreMismatch
|
|
|
|
|
2016-07-21 22:29:48 +08:00
|
|
|
[1-SNI-keep-context-client-extra]
|
|
|
|
ServerName = server1
|
|
|
|
|
2016-06-20 23:20:25 +08:00
|
|
|
|
|
|
|
# ===========================================================
|
|
|
|
|
|
|
|
[2-SNI-no-server-support]
|
|
|
|
ssl_conf = 2-SNI-no-server-support-ssl
|
|
|
|
|
|
|
|
[2-SNI-no-server-support-ssl]
|
|
|
|
server = 2-SNI-no-server-support-server
|
|
|
|
client = 2-SNI-no-server-support-client
|
|
|
|
|
|
|
|
[2-SNI-no-server-support-server]
|
|
|
|
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
|
|
|
|
CipherString = DEFAULT
|
|
|
|
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
|
|
|
|
|
|
|
|
[2-SNI-no-server-support-client]
|
|
|
|
CipherString = DEFAULT
|
|
|
|
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
|
|
|
|
VerifyMode = Peer
|
|
|
|
|
|
|
|
[test-2]
|
|
|
|
ExpectedResult = Success
|
2016-07-21 22:29:48 +08:00
|
|
|
client = 2-SNI-no-server-support-client-extra
|
|
|
|
|
|
|
|
[2-SNI-no-server-support-client-extra]
|
2016-06-20 23:20:25 +08:00
|
|
|
ServerName = server1
|
|
|
|
|
|
|
|
|
|
|
|
# ===========================================================
|
|
|
|
|
|
|
|
[3-SNI-no-client-support]
|
|
|
|
ssl_conf = 3-SNI-no-client-support-ssl
|
|
|
|
|
|
|
|
[3-SNI-no-client-support-ssl]
|
|
|
|
server = 3-SNI-no-client-support-server
|
|
|
|
client = 3-SNI-no-client-support-client
|
2016-07-22 01:19:07 +08:00
|
|
|
server2 = 3-SNI-no-client-support-server
|
2016-06-20 23:20:25 +08:00
|
|
|
|
|
|
|
[3-SNI-no-client-support-server]
|
|
|
|
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
|
|
|
|
CipherString = DEFAULT
|
|
|
|
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
|
|
|
|
|
|
|
|
[3-SNI-no-client-support-client]
|
|
|
|
CipherString = DEFAULT
|
|
|
|
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
|
|
|
|
VerifyMode = Peer
|
|
|
|
|
|
|
|
[test-3]
|
|
|
|
ExpectedResult = Success
|
|
|
|
ExpectedServerName = server1
|
2016-07-21 22:29:48 +08:00
|
|
|
server = 3-SNI-no-client-support-server-extra
|
|
|
|
server2 = 3-SNI-no-client-support-server-extra
|
|
|
|
|
|
|
|
[3-SNI-no-client-support-server-extra]
|
2016-06-20 23:20:25 +08:00
|
|
|
ServerNameCallback = IgnoreMismatch
|
|
|
|
|
|
|
|
|
|
|
|
# ===========================================================
|
|
|
|
|
|
|
|
[4-SNI-bad-sni-ignore-mismatch]
|
|
|
|
ssl_conf = 4-SNI-bad-sni-ignore-mismatch-ssl
|
|
|
|
|
|
|
|
[4-SNI-bad-sni-ignore-mismatch-ssl]
|
|
|
|
server = 4-SNI-bad-sni-ignore-mismatch-server
|
|
|
|
client = 4-SNI-bad-sni-ignore-mismatch-client
|
2016-07-22 01:19:07 +08:00
|
|
|
server2 = 4-SNI-bad-sni-ignore-mismatch-server
|
2016-06-20 23:20:25 +08:00
|
|
|
|
|
|
|
[4-SNI-bad-sni-ignore-mismatch-server]
|
|
|
|
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
|
|
|
|
CipherString = DEFAULT
|
|
|
|
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
|
|
|
|
|
|
|
|
[4-SNI-bad-sni-ignore-mismatch-client]
|
|
|
|
CipherString = DEFAULT
|
|
|
|
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
|
|
|
|
VerifyMode = Peer
|
|
|
|
|
|
|
|
[test-4]
|
|
|
|
ExpectedResult = Success
|
|
|
|
ExpectedServerName = server1
|
2016-07-21 22:29:48 +08:00
|
|
|
server = 4-SNI-bad-sni-ignore-mismatch-server-extra
|
|
|
|
server2 = 4-SNI-bad-sni-ignore-mismatch-server-extra
|
|
|
|
client = 4-SNI-bad-sni-ignore-mismatch-client-extra
|
|
|
|
|
|
|
|
[4-SNI-bad-sni-ignore-mismatch-server-extra]
|
2016-06-20 23:20:25 +08:00
|
|
|
ServerNameCallback = IgnoreMismatch
|
|
|
|
|
2016-07-21 22:29:48 +08:00
|
|
|
[4-SNI-bad-sni-ignore-mismatch-client-extra]
|
|
|
|
ServerName = invalid
|
|
|
|
|
2016-06-20 23:20:25 +08:00
|
|
|
|
|
|
|
# ===========================================================
|
|
|
|
|
|
|
|
[5-SNI-bad-sni-reject-mismatch]
|
|
|
|
ssl_conf = 5-SNI-bad-sni-reject-mismatch-ssl
|
|
|
|
|
|
|
|
[5-SNI-bad-sni-reject-mismatch-ssl]
|
|
|
|
server = 5-SNI-bad-sni-reject-mismatch-server
|
|
|
|
client = 5-SNI-bad-sni-reject-mismatch-client
|
2016-07-22 01:19:07 +08:00
|
|
|
server2 = 5-SNI-bad-sni-reject-mismatch-server
|
2016-06-20 23:20:25 +08:00
|
|
|
|
|
|
|
[5-SNI-bad-sni-reject-mismatch-server]
|
|
|
|
Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
|
|
|
|
CipherString = DEFAULT
|
|
|
|
PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
|
|
|
|
|
|
|
|
[5-SNI-bad-sni-reject-mismatch-client]
|
|
|
|
CipherString = DEFAULT
|
|
|
|
VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
|
|
|
|
VerifyMode = Peer
|
|
|
|
|
|
|
|
[test-5]
|
|
|
|
ExpectedResult = ServerFail
|
2016-07-21 22:29:48 +08:00
|
|
|
ExpectedServerAlert = UnrecognizedName
|
|
|
|
server = 5-SNI-bad-sni-reject-mismatch-server-extra
|
|
|
|
server2 = 5-SNI-bad-sni-reject-mismatch-server-extra
|
|
|
|
client = 5-SNI-bad-sni-reject-mismatch-client-extra
|
|
|
|
|
|
|
|
[5-SNI-bad-sni-reject-mismatch-server-extra]
|
2016-06-20 23:20:25 +08:00
|
|
|
ServerNameCallback = RejectMismatch
|
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
|
|
|
|
2016-07-21 22:29:48 +08:00
|
|
|
[5-SNI-bad-sni-reject-mismatch-client-extra]
|
|
|
|
ServerName = invalid
|
|
|
|
|
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
|
|
|
|