openssl/doc/man3/SSL_want.pod

121 lines
3.7 KiB
Plaintext
Raw Normal View History

=pod
=head1 NAME
TLS client: allow cert verify callback return -1 for SSL_ERROR_WANT_RETRY_VERIFY The client-side cert verification callback function may not only return as usual for success or 0 for failure, but also -1, typically on failure verifying the server certificate. This makes the handshake suspend and return control to the calling application with SSL_ERROR_WANT_RETRY_VERIFY. The app can for instance fetch further certificates or cert status information needed for the verification. Calling SSL_connect() again resumes the connection attempt by retrying the server certificate verification step. This process may even be repeated if need be. The core implementation of the feature is in ssl/statem/statem_clnt.c, splitting tls_process_server_certificate() into a preparation step that just copies the certificates received from the server to s->session->peer_chain (rather than having them in a local variable at first) and returns to the state machine, and a post-processing step in tls_post_process_server_certificate() that can be repeated: Try verifying the current contents of s->session->peer_chain basically as before, but give the verification callback function the chance to pause connecting and make the TLS state machine later call tls_post_process_server_certificate() again. Otherwise processing continues as usual. The documentation of the new feature is added to SSL_CTX_set_cert_verify_callback.pod and SSL_want.pod. This adds two tests: * A generic test in test/helpers/handshake.c on the usability of the new server cert verification retry feature. It is triggered via test/ssl-tests/03-custom_verify.cnf.in (while the bulky auto- generated changes to test/ssl-tests/03-custom_verify.cnf can be basically ignored). * A test in test/sslapitest.c that demonstrates the effectiveness of the approach for augmenting the cert chain provided by the server in between SSL_connect() calls. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13906)
2021-01-17 03:43:00 +08:00
SSL_want, SSL_want_nothing, SSL_want_read, SSL_want_write,
SSL_want_x509_lookup, SSL_want_retry_verify, SSL_want_async, SSL_want_async_job,
SSL_want_client_hello_cb - obtain state information TLS/SSL I/O operation
=head1 SYNOPSIS
#include <openssl/ssl.h>
2005-03-30 19:50:14 +08:00
int SSL_want(const SSL *ssl);
int SSL_want_nothing(const SSL *ssl);
int SSL_want_read(const SSL *ssl);
int SSL_want_write(const SSL *ssl);
int SSL_want_x509_lookup(const SSL *ssl);
TLS client: allow cert verify callback return -1 for SSL_ERROR_WANT_RETRY_VERIFY The client-side cert verification callback function may not only return as usual for success or 0 for failure, but also -1, typically on failure verifying the server certificate. This makes the handshake suspend and return control to the calling application with SSL_ERROR_WANT_RETRY_VERIFY. The app can for instance fetch further certificates or cert status information needed for the verification. Calling SSL_connect() again resumes the connection attempt by retrying the server certificate verification step. This process may even be repeated if need be. The core implementation of the feature is in ssl/statem/statem_clnt.c, splitting tls_process_server_certificate() into a preparation step that just copies the certificates received from the server to s->session->peer_chain (rather than having them in a local variable at first) and returns to the state machine, and a post-processing step in tls_post_process_server_certificate() that can be repeated: Try verifying the current contents of s->session->peer_chain basically as before, but give the verification callback function the chance to pause connecting and make the TLS state machine later call tls_post_process_server_certificate() again. Otherwise processing continues as usual. The documentation of the new feature is added to SSL_CTX_set_cert_verify_callback.pod and SSL_want.pod. This adds two tests: * A generic test in test/helpers/handshake.c on the usability of the new server cert verification retry feature. It is triggered via test/ssl-tests/03-custom_verify.cnf.in (while the bulky auto- generated changes to test/ssl-tests/03-custom_verify.cnf can be basically ignored). * A test in test/sslapitest.c that demonstrates the effectiveness of the approach for augmenting the cert chain provided by the server in between SSL_connect() calls. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13906)
2021-01-17 03:43:00 +08:00
int SSL_want_retry_verify(const SSL *ssl);
int SSL_want_async(const SSL *ssl);
int SSL_want_async_job(const SSL *ssl);
int SSL_want_client_hello_cb(const SSL *ssl);
=head1 DESCRIPTION
SSL_want() returns state information for the SSL object B<ssl>.
The other SSL_want_*() calls are shortcuts for the possible states returned
by SSL_want().
=head1 NOTES
SSL_want() examines the internal state information of the SSL object. Its
return values are similar to that of L<SSL_get_error(3)>.
Unlike L<SSL_get_error(3)>, which also evaluates the
error queue, the results are obtained by examining an internal state flag
only. The information must therefore only be used for normal operation under
nonblocking I/O. Error conditions are not handled and must be treated
using L<SSL_get_error(3)>.
The result returned by SSL_want() should always be consistent with
the result of L<SSL_get_error(3)>.
=head1 RETURN VALUES
The following return values can currently occur for SSL_want():
=over 4
=item SSL_NOTHING
There is no data to be written or to be read.
=item SSL_WRITING
There are data in the SSL buffer that must be written to the underlying
B<BIO> layer in order to complete the actual SSL_*() operation.
TLS client: allow cert verify callback return -1 for SSL_ERROR_WANT_RETRY_VERIFY The client-side cert verification callback function may not only return as usual for success or 0 for failure, but also -1, typically on failure verifying the server certificate. This makes the handshake suspend and return control to the calling application with SSL_ERROR_WANT_RETRY_VERIFY. The app can for instance fetch further certificates or cert status information needed for the verification. Calling SSL_connect() again resumes the connection attempt by retrying the server certificate verification step. This process may even be repeated if need be. The core implementation of the feature is in ssl/statem/statem_clnt.c, splitting tls_process_server_certificate() into a preparation step that just copies the certificates received from the server to s->session->peer_chain (rather than having them in a local variable at first) and returns to the state machine, and a post-processing step in tls_post_process_server_certificate() that can be repeated: Try verifying the current contents of s->session->peer_chain basically as before, but give the verification callback function the chance to pause connecting and make the TLS state machine later call tls_post_process_server_certificate() again. Otherwise processing continues as usual. The documentation of the new feature is added to SSL_CTX_set_cert_verify_callback.pod and SSL_want.pod. This adds two tests: * A generic test in test/helpers/handshake.c on the usability of the new server cert verification retry feature. It is triggered via test/ssl-tests/03-custom_verify.cnf.in (while the bulky auto- generated changes to test/ssl-tests/03-custom_verify.cnf can be basically ignored). * A test in test/sslapitest.c that demonstrates the effectiveness of the approach for augmenting the cert chain provided by the server in between SSL_connect() calls. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13906)
2021-01-17 03:43:00 +08:00
A call to L<SSL_get_error(3)> should return B<SSL_ERROR_WANT_WRITE>.
=item SSL_READING
More data must be read from the underlying B<BIO> layer in order to
complete the actual SSL_*() operation.
TLS client: allow cert verify callback return -1 for SSL_ERROR_WANT_RETRY_VERIFY The client-side cert verification callback function may not only return as usual for success or 0 for failure, but also -1, typically on failure verifying the server certificate. This makes the handshake suspend and return control to the calling application with SSL_ERROR_WANT_RETRY_VERIFY. The app can for instance fetch further certificates or cert status information needed for the verification. Calling SSL_connect() again resumes the connection attempt by retrying the server certificate verification step. This process may even be repeated if need be. The core implementation of the feature is in ssl/statem/statem_clnt.c, splitting tls_process_server_certificate() into a preparation step that just copies the certificates received from the server to s->session->peer_chain (rather than having them in a local variable at first) and returns to the state machine, and a post-processing step in tls_post_process_server_certificate() that can be repeated: Try verifying the current contents of s->session->peer_chain basically as before, but give the verification callback function the chance to pause connecting and make the TLS state machine later call tls_post_process_server_certificate() again. Otherwise processing continues as usual. The documentation of the new feature is added to SSL_CTX_set_cert_verify_callback.pod and SSL_want.pod. This adds two tests: * A generic test in test/helpers/handshake.c on the usability of the new server cert verification retry feature. It is triggered via test/ssl-tests/03-custom_verify.cnf.in (while the bulky auto- generated changes to test/ssl-tests/03-custom_verify.cnf can be basically ignored). * A test in test/sslapitest.c that demonstrates the effectiveness of the approach for augmenting the cert chain provided by the server in between SSL_connect() calls. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13906)
2021-01-17 03:43:00 +08:00
A call to L<SSL_get_error(3)> should return B<SSL_ERROR_WANT_READ>.
=item SSL_X509_LOOKUP
The operation did not complete because an application callback set by
SSL_CTX_set_client_cert_cb() has asked to be called again.
TLS client: allow cert verify callback return -1 for SSL_ERROR_WANT_RETRY_VERIFY The client-side cert verification callback function may not only return as usual for success or 0 for failure, but also -1, typically on failure verifying the server certificate. This makes the handshake suspend and return control to the calling application with SSL_ERROR_WANT_RETRY_VERIFY. The app can for instance fetch further certificates or cert status information needed for the verification. Calling SSL_connect() again resumes the connection attempt by retrying the server certificate verification step. This process may even be repeated if need be. The core implementation of the feature is in ssl/statem/statem_clnt.c, splitting tls_process_server_certificate() into a preparation step that just copies the certificates received from the server to s->session->peer_chain (rather than having them in a local variable at first) and returns to the state machine, and a post-processing step in tls_post_process_server_certificate() that can be repeated: Try verifying the current contents of s->session->peer_chain basically as before, but give the verification callback function the chance to pause connecting and make the TLS state machine later call tls_post_process_server_certificate() again. Otherwise processing continues as usual. The documentation of the new feature is added to SSL_CTX_set_cert_verify_callback.pod and SSL_want.pod. This adds two tests: * A generic test in test/helpers/handshake.c on the usability of the new server cert verification retry feature. It is triggered via test/ssl-tests/03-custom_verify.cnf.in (while the bulky auto- generated changes to test/ssl-tests/03-custom_verify.cnf can be basically ignored). * A test in test/sslapitest.c that demonstrates the effectiveness of the approach for augmenting the cert chain provided by the server in between SSL_connect() calls. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13906)
2021-01-17 03:43:00 +08:00
A call to L<SSL_get_error(3)> should return B<SSL_ERROR_WANT_X509_LOOKUP>.
=item SSL_RETRY_VERIFY
The operation did not complete because a certificate verification callback
has asked to be called again via L<SSL_set_retry_verify(3)>.
TLS client: allow cert verify callback return -1 for SSL_ERROR_WANT_RETRY_VERIFY The client-side cert verification callback function may not only return as usual for success or 0 for failure, but also -1, typically on failure verifying the server certificate. This makes the handshake suspend and return control to the calling application with SSL_ERROR_WANT_RETRY_VERIFY. The app can for instance fetch further certificates or cert status information needed for the verification. Calling SSL_connect() again resumes the connection attempt by retrying the server certificate verification step. This process may even be repeated if need be. The core implementation of the feature is in ssl/statem/statem_clnt.c, splitting tls_process_server_certificate() into a preparation step that just copies the certificates received from the server to s->session->peer_chain (rather than having them in a local variable at first) and returns to the state machine, and a post-processing step in tls_post_process_server_certificate() that can be repeated: Try verifying the current contents of s->session->peer_chain basically as before, but give the verification callback function the chance to pause connecting and make the TLS state machine later call tls_post_process_server_certificate() again. Otherwise processing continues as usual. The documentation of the new feature is added to SSL_CTX_set_cert_verify_callback.pod and SSL_want.pod. This adds two tests: * A generic test in test/helpers/handshake.c on the usability of the new server cert verification retry feature. It is triggered via test/ssl-tests/03-custom_verify.cnf.in (while the bulky auto- generated changes to test/ssl-tests/03-custom_verify.cnf can be basically ignored). * A test in test/sslapitest.c that demonstrates the effectiveness of the approach for augmenting the cert chain provided by the server in between SSL_connect() calls. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13906)
2021-01-17 03:43:00 +08:00
A call to L<SSL_get_error(3)> should return B<SSL_ERROR_WANT_RETRY_VERIFY>.
=item SSL_ASYNC_PAUSED
An asynchronous operation partially completed and was then paused. See
L<SSL_get_all_async_fds(3)>. A call to L<SSL_get_error(3)> should return
TLS client: allow cert verify callback return -1 for SSL_ERROR_WANT_RETRY_VERIFY The client-side cert verification callback function may not only return as usual for success or 0 for failure, but also -1, typically on failure verifying the server certificate. This makes the handshake suspend and return control to the calling application with SSL_ERROR_WANT_RETRY_VERIFY. The app can for instance fetch further certificates or cert status information needed for the verification. Calling SSL_connect() again resumes the connection attempt by retrying the server certificate verification step. This process may even be repeated if need be. The core implementation of the feature is in ssl/statem/statem_clnt.c, splitting tls_process_server_certificate() into a preparation step that just copies the certificates received from the server to s->session->peer_chain (rather than having them in a local variable at first) and returns to the state machine, and a post-processing step in tls_post_process_server_certificate() that can be repeated: Try verifying the current contents of s->session->peer_chain basically as before, but give the verification callback function the chance to pause connecting and make the TLS state machine later call tls_post_process_server_certificate() again. Otherwise processing continues as usual. The documentation of the new feature is added to SSL_CTX_set_cert_verify_callback.pod and SSL_want.pod. This adds two tests: * A generic test in test/helpers/handshake.c on the usability of the new server cert verification retry feature. It is triggered via test/ssl-tests/03-custom_verify.cnf.in (while the bulky auto- generated changes to test/ssl-tests/03-custom_verify.cnf can be basically ignored). * A test in test/sslapitest.c that demonstrates the effectiveness of the approach for augmenting the cert chain provided by the server in between SSL_connect() calls. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13906)
2021-01-17 03:43:00 +08:00
B<SSL_ERROR_WANT_ASYNC>.
=item SSL_ASYNC_NO_JOBS
The asynchronous job could not be started because there were no async jobs
available in the pool (see ASYNC_init_thread(3)). A call to L<SSL_get_error(3)>
TLS client: allow cert verify callback return -1 for SSL_ERROR_WANT_RETRY_VERIFY The client-side cert verification callback function may not only return as usual for success or 0 for failure, but also -1, typically on failure verifying the server certificate. This makes the handshake suspend and return control to the calling application with SSL_ERROR_WANT_RETRY_VERIFY. The app can for instance fetch further certificates or cert status information needed for the verification. Calling SSL_connect() again resumes the connection attempt by retrying the server certificate verification step. This process may even be repeated if need be. The core implementation of the feature is in ssl/statem/statem_clnt.c, splitting tls_process_server_certificate() into a preparation step that just copies the certificates received from the server to s->session->peer_chain (rather than having them in a local variable at first) and returns to the state machine, and a post-processing step in tls_post_process_server_certificate() that can be repeated: Try verifying the current contents of s->session->peer_chain basically as before, but give the verification callback function the chance to pause connecting and make the TLS state machine later call tls_post_process_server_certificate() again. Otherwise processing continues as usual. The documentation of the new feature is added to SSL_CTX_set_cert_verify_callback.pod and SSL_want.pod. This adds two tests: * A generic test in test/helpers/handshake.c on the usability of the new server cert verification retry feature. It is triggered via test/ssl-tests/03-custom_verify.cnf.in (while the bulky auto- generated changes to test/ssl-tests/03-custom_verify.cnf can be basically ignored). * A test in test/sslapitest.c that demonstrates the effectiveness of the approach for augmenting the cert chain provided by the server in between SSL_connect() calls. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13906)
2021-01-17 03:43:00 +08:00
should return B<SSL_ERROR_WANT_ASYNC_JOB>.
=item SSL_CLIENT_HELLO_CB
Add SSL_CTX early callback Provide a callback interface that gives the application the ability to adjust the nascent SSL object at the earliest stage of ClientHello processing, immediately after extensions have been collected but before they have been processed. This is akin to BoringSSL's "select_certificate_cb" (though it is not API compatible), and as the name indicates, one major use is to examine the supplied server name indication and select what certificate to present to the client. However, it can also be used to make more sweeping configuration changes to the SSL object according to the selected server identity and configuration. That may include adjusting the permitted TLS versions, swapping out the SSL_CTX object (as is traditionally done in a tlsext_servername_callback), changing the server's cipher list, and more. We also wish to allow an early callback to indicate that it needs to perform additional work asynchronously and resume processing later. To that effect, refactor the second half of tls_process_client_hello() into a subroutine to be called at the post-processing stage (including the early callback itself), to allow the callback to result in remaining in the same work stage for a later call to succeed. This requires allocating for and storing the CLIENTHELLO_MSG in the SSL object to be preserved across such calls, but the storage is reclaimed after ClientHello processing finishes. Information about the CliehtHello is available to the callback by means of accessor functions that can only be used from the early callback. This allows extensions to make use of the existing internal parsing machinery without exposing structure internals (e.g., of PACKET), so that applications do not have to write fragile parsing code. Applications are encouraged to utilize an early callback and not use a servername_callback, in order to avoid unexpected behavior that occurs due to the relative order of processing between things like session resumption and the historical servername callback. Also tidy up nearby style by removing unnecessary braces around one-line conditional bodies. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2279)
2017-01-24 07:03:16 +08:00
The operation did not complete because an application callback set by
SSL_CTX_set_client_hello_cb() has asked to be called again.
TLS client: allow cert verify callback return -1 for SSL_ERROR_WANT_RETRY_VERIFY The client-side cert verification callback function may not only return as usual for success or 0 for failure, but also -1, typically on failure verifying the server certificate. This makes the handshake suspend and return control to the calling application with SSL_ERROR_WANT_RETRY_VERIFY. The app can for instance fetch further certificates or cert status information needed for the verification. Calling SSL_connect() again resumes the connection attempt by retrying the server certificate verification step. This process may even be repeated if need be. The core implementation of the feature is in ssl/statem/statem_clnt.c, splitting tls_process_server_certificate() into a preparation step that just copies the certificates received from the server to s->session->peer_chain (rather than having them in a local variable at first) and returns to the state machine, and a post-processing step in tls_post_process_server_certificate() that can be repeated: Try verifying the current contents of s->session->peer_chain basically as before, but give the verification callback function the chance to pause connecting and make the TLS state machine later call tls_post_process_server_certificate() again. Otherwise processing continues as usual. The documentation of the new feature is added to SSL_CTX_set_cert_verify_callback.pod and SSL_want.pod. This adds two tests: * A generic test in test/helpers/handshake.c on the usability of the new server cert verification retry feature. It is triggered via test/ssl-tests/03-custom_verify.cnf.in (while the bulky auto- generated changes to test/ssl-tests/03-custom_verify.cnf can be basically ignored). * A test in test/sslapitest.c that demonstrates the effectiveness of the approach for augmenting the cert chain provided by the server in between SSL_connect() calls. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13906)
2021-01-17 03:43:00 +08:00
A call to L<SSL_get_error(3)> should return B<SSL_ERROR_WANT_CLIENT_HELLO_CB>.
Add SSL_CTX early callback Provide a callback interface that gives the application the ability to adjust the nascent SSL object at the earliest stage of ClientHello processing, immediately after extensions have been collected but before they have been processed. This is akin to BoringSSL's "select_certificate_cb" (though it is not API compatible), and as the name indicates, one major use is to examine the supplied server name indication and select what certificate to present to the client. However, it can also be used to make more sweeping configuration changes to the SSL object according to the selected server identity and configuration. That may include adjusting the permitted TLS versions, swapping out the SSL_CTX object (as is traditionally done in a tlsext_servername_callback), changing the server's cipher list, and more. We also wish to allow an early callback to indicate that it needs to perform additional work asynchronously and resume processing later. To that effect, refactor the second half of tls_process_client_hello() into a subroutine to be called at the post-processing stage (including the early callback itself), to allow the callback to result in remaining in the same work stage for a later call to succeed. This requires allocating for and storing the CLIENTHELLO_MSG in the SSL object to be preserved across such calls, but the storage is reclaimed after ClientHello processing finishes. Information about the CliehtHello is available to the callback by means of accessor functions that can only be used from the early callback. This allows extensions to make use of the existing internal parsing machinery without exposing structure internals (e.g., of PACKET), so that applications do not have to write fragile parsing code. Applications are encouraged to utilize an early callback and not use a servername_callback, in order to avoid unexpected behavior that occurs due to the relative order of processing between things like session resumption and the historical servername callback. Also tidy up nearby style by removing unnecessary braces around one-line conditional bodies. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2279)
2017-01-24 07:03:16 +08:00
=back
TLS client: allow cert verify callback return -1 for SSL_ERROR_WANT_RETRY_VERIFY The client-side cert verification callback function may not only return as usual for success or 0 for failure, but also -1, typically on failure verifying the server certificate. This makes the handshake suspend and return control to the calling application with SSL_ERROR_WANT_RETRY_VERIFY. The app can for instance fetch further certificates or cert status information needed for the verification. Calling SSL_connect() again resumes the connection attempt by retrying the server certificate verification step. This process may even be repeated if need be. The core implementation of the feature is in ssl/statem/statem_clnt.c, splitting tls_process_server_certificate() into a preparation step that just copies the certificates received from the server to s->session->peer_chain (rather than having them in a local variable at first) and returns to the state machine, and a post-processing step in tls_post_process_server_certificate() that can be repeated: Try verifying the current contents of s->session->peer_chain basically as before, but give the verification callback function the chance to pause connecting and make the TLS state machine later call tls_post_process_server_certificate() again. Otherwise processing continues as usual. The documentation of the new feature is added to SSL_CTX_set_cert_verify_callback.pod and SSL_want.pod. This adds two tests: * A generic test in test/helpers/handshake.c on the usability of the new server cert verification retry feature. It is triggered via test/ssl-tests/03-custom_verify.cnf.in (while the bulky auto- generated changes to test/ssl-tests/03-custom_verify.cnf can be basically ignored). * A test in test/sslapitest.c that demonstrates the effectiveness of the approach for augmenting the cert chain provided by the server in between SSL_connect() calls. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13906)
2021-01-17 03:43:00 +08:00
SSL_want_nothing(), SSL_want_read(), SSL_want_write(),
SSL_want_x509_lookup(), SSL_want_retry_verify(),
SSL_want_async(), SSL_want_async_job(), and SSL_want_client_hello_cb()
return 1 when the corresponding condition is true or 0 otherwise.
=head1 SEE ALSO
L<ssl(7)>, L<SSL_get_error(3)>
Add SSL_CTX early callback Provide a callback interface that gives the application the ability to adjust the nascent SSL object at the earliest stage of ClientHello processing, immediately after extensions have been collected but before they have been processed. This is akin to BoringSSL's "select_certificate_cb" (though it is not API compatible), and as the name indicates, one major use is to examine the supplied server name indication and select what certificate to present to the client. However, it can also be used to make more sweeping configuration changes to the SSL object according to the selected server identity and configuration. That may include adjusting the permitted TLS versions, swapping out the SSL_CTX object (as is traditionally done in a tlsext_servername_callback), changing the server's cipher list, and more. We also wish to allow an early callback to indicate that it needs to perform additional work asynchronously and resume processing later. To that effect, refactor the second half of tls_process_client_hello() into a subroutine to be called at the post-processing stage (including the early callback itself), to allow the callback to result in remaining in the same work stage for a later call to succeed. This requires allocating for and storing the CLIENTHELLO_MSG in the SSL object to be preserved across such calls, but the storage is reclaimed after ClientHello processing finishes. Information about the CliehtHello is available to the callback by means of accessor functions that can only be used from the early callback. This allows extensions to make use of the existing internal parsing machinery without exposing structure internals (e.g., of PACKET), so that applications do not have to write fragile parsing code. Applications are encouraged to utilize an early callback and not use a servername_callback, in order to avoid unexpected behavior that occurs due to the relative order of processing between things like session resumption and the historical servername callback. Also tidy up nearby style by removing unnecessary braces around one-line conditional bodies. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2279)
2017-01-24 07:03:16 +08:00
=head1 HISTORY
The SSL_want_client_hello_cb() function and the SSL_CLIENT_HELLO_CB return value
were added in OpenSSL 1.1.1.
Add SSL_CTX early callback Provide a callback interface that gives the application the ability to adjust the nascent SSL object at the earliest stage of ClientHello processing, immediately after extensions have been collected but before they have been processed. This is akin to BoringSSL's "select_certificate_cb" (though it is not API compatible), and as the name indicates, one major use is to examine the supplied server name indication and select what certificate to present to the client. However, it can also be used to make more sweeping configuration changes to the SSL object according to the selected server identity and configuration. That may include adjusting the permitted TLS versions, swapping out the SSL_CTX object (as is traditionally done in a tlsext_servername_callback), changing the server's cipher list, and more. We also wish to allow an early callback to indicate that it needs to perform additional work asynchronously and resume processing later. To that effect, refactor the second half of tls_process_client_hello() into a subroutine to be called at the post-processing stage (including the early callback itself), to allow the callback to result in remaining in the same work stage for a later call to succeed. This requires allocating for and storing the CLIENTHELLO_MSG in the SSL object to be preserved across such calls, but the storage is reclaimed after ClientHello processing finishes. Information about the CliehtHello is available to the callback by means of accessor functions that can only be used from the early callback. This allows extensions to make use of the existing internal parsing machinery without exposing structure internals (e.g., of PACKET), so that applications do not have to write fragile parsing code. Applications are encouraged to utilize an early callback and not use a servername_callback, in order to avoid unexpected behavior that occurs due to the relative order of processing between things like session resumption and the historical servername callback. Also tidy up nearby style by removing unnecessary braces around one-line conditional bodies. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2279)
2017-01-24 07:03:16 +08:00
=head1 COPYRIGHT
Copyright 2001-2022 The OpenSSL Project Authors. All Rights Reserved.
Licensed under the Apache License 2.0 (the "License"). You may not use
this file except in compliance with the License. You can obtain a copy
in the file LICENSE in the source distribution or at
L<https://www.openssl.org/source/license.html>.
=cut