SSL_state_string contains the code:
#if !defined(OPENSSL_NO_SSL2) && !defined(OPENSSL_NO_SSL3)
/* SSLv2/v3 compatibility states */
/* client */
case SSL23_ST_CW_CLNT_HELLO_A: str="23WCHA"; break;
case SSL23_ST_CW_CLNT_HELLO_B: str="23WCHB"; break;
case SSL23_ST_CR_SRVR_HELLO_A: str="23RSHA"; break;
case SSL23_ST_CR_SRVR_HELLO_B: str="23RSHA"; break;
/* server */
case SSL23_ST_SR_CLNT_HELLO_A: str="23RCHA"; break;
case SSL23_ST_SR_CLNT_HELLO_B: str="23RCHB"; break;
#endif
...
default: str="UNKWN "; break;
However, openssl can enter at least some of the above states even when
OPENSSL_NO_SSL2 is defined. For example, in s23_clnt.c:
IMPLEMENT_ssl23_meth_func(SSLv23_client_method,
ssl_undefined_function,
ssl23_connect,
ssl23_get_client_method)
SSLv23_client_method is a public API which can certainly be called when
OPENSSL_NO_SSL2 is not defined; in this case it's just expected to not actually
use SSLv2. So if the user calls this, ssl23_connect will be called to handle
connections. And ssl23_connect contains lines to set the state:
s->state=SSL23_ST_CW_CLNT_HELLO_A;
s->state=SSL23_ST_CR_SRVR_HELLO_A;
s->state=SSL23_ST_CW_CLNT_HELLO_B;
None of these state transitions are guarded by OPENSSL_NO_SSL2 defines.
So, if OPENSSL_NO_SSL2 is defined, openssl CAN enter the 3 states above, but if
SSL_state_string is called while in these states, UNKNWN is returned, because
the code that handles these 3 states is only defined when OPENSSL_NO_SSL2 is
not defined.
I don't know if there are similar problems for any other states. It looks like
SSL_state_string_long has the same problem.
It looks ilk SSL_state_string_long
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
