hi!
i found a really nasty bug in the ssl code. i can describe it, but i cannot offer a solution, because the code is so complex and full of special conditions. okey, the bug: ssl3_read_internal function has special treatment for situations when renegotiation is going on and the handshake and data packets are arriving in random order. now, if i have a non-blocking socket on server side and i use BIO SSL interface to access it, without performing an explicit handshake using BIO_do_handshake or SSL_accept before i start usign BIO_read, then following may happen: 1) application calls BIO_read that will finally call ssl3_read_internal. 2) inside ssl3_read_internal the in_read_app_data flag is set. 3) ssl3_read_internal calls ssl3_read_bytes that will determine that handshake is not performed and calls handshake function that in my case was ssl3_accept. 4) ssl3_accept determines that the statemachine is never used before and will call SSL_clear. 5) SSL_clear will reset in_read_app_data flag (actually it's ssl3_clear that clears the flag). 6) ssl3_accept will advance the state machine and tries to read the Client Hello message 7) when the Client Hello is not yet available (non-blokcing socket), it will return with an error. 8) now the condition inside ssl3_read_internal function will be erronosly satisfied: there is error present from ssl3_read_bytes function and the in_read_app_data is reset. 9) ssl3_read_internal now tries to read application data packet from socket. 10) if the data is still not available the second call to ssl3_read_bytes will return with an error and everthing will continue nicely. 11) but, if the data (Client Hello) arrived between the two calls to the ssl3_read_bytes function, then a fatal error will occur and the handshake will fail. ssl3_read_bytes will read the frame and it will check the frame type. it expected an application data but it got a handshake frame. btw, there is comment inside ssl3_read_bytes: /* we already handled all of these, with the possible exception * of SSL3_RT_HANDSHAKE when s->in_handshake is set, but that * should not happen when type != rr->type */ but that is exactly what happens and application will get internal error (aka bug). i don't know what the correct solution to this problem is. perhaps the call to SSL_clear should be removed from ssl3_accept (and from other related functions). but there are too many ways to initiate and perform a SSL handshake, that i'm afraid to try and test this. i solved my problem for now by calling the BIO_do_handshake function once before i start using BIO_reads. this will advance the statmachine past the point where ssl3_accept will call SSL_clear, but it would be nice to have solution inside OpenSSL. arne ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
