On Tue, Jun 20, 2006 at 07:50:24PM -0700, David Schwartz wrote:
> You could argue that we could just fix this and deprecate "fake
> non-blocking I/O" for future major versions. The argument would be that this
> won't break any application that's not broken already and might fix existing
> applications.
Regardless of the merits of single read() per SSL-read() or not. Two
observations:
1. The code path in question only applies to SSLv3 and TLSv1. The SSLv2
code does not look at the RETRY flag, likely because SSLv2 does not
support data in the middle of a handshake.
2. The code is question is ssl3_read_internal():
static int ssl3_read_internal(SSL *s, void *buf, int len, int peek)
{
int ret;
clear_sys_error();
if (s->s3->renegotiate) ssl3_renegotiate_check(s);
s->s3->in_read_app_data=1;
ret=s->method->ssl_read_bytes(s,SSL3_RT_APPLICATION_DATA,buf,len,peek);
if ((ret == -1) && (s->s3->in_read_app_data == 2))
{
/* ssl3_read_bytes decided to call s->handshake_func, which
* called ssl3_read_bytes to read handshake data.
* However, ssl3_read_bytes actually found application data
* and thinks that application data makes sense here; so disable
* handshake processing and try to read application data again. */
s->in_handshake++;
ret=s->method->ssl_read_bytes(s,SSL3_RT_APPLICATION_DATA,buf,len,peek);
s->in_handshake--;
}
else
s->s3->in_read_app_data=0;
return(ret);
}
That second ssl3_read_bytes() is called when "in_read_app_data == 2",
which is set when data arrives when a handshake was expected.
case SSL3_RT_APPLICATION_DATA:
/* At this point, we were expecting handshake data,
* but have application data. If the library was
* running inside ssl3_read() (i.e. in_read_app_data
* is set) and it makes sense to read application data
* at this point (session renegotiation not yet started),
* we will indulge it.
*/
if (s->s3->in_read_app_data &&
(s->s3->total_renegotiations != 0) &&
((
(s->state & SSL_ST_CONNECT) &&
(s->state >= SSL3_ST_CW_CLNT_HELLO_A) &&
(s->state <= SSL3_ST_CR_SRVR_HELLO_A)
) || (
(s->state & SSL_ST_ACCEPT) &&
(s->state <= SSL3_ST_SW_HELLO_REQ_A) &&
(s->state >= SSL3_ST_SR_CLNT_HELLO_A)
)
))
{
s->s3->in_read_app_data=2;
return(-1);
}
Perhaps the backtracking to reprocess the event as data involves a
second blocking socket read() in ssl3_read_bytes(). I am not familiar
with the details of this code. What I am curious about is when does
this happen. What is it exactly that the server is doing here, why,
and is it legal?
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
