Lidong Zhou <[EMAIL PROTECTED]>:
> BUG1:
> Symptom: If we run the provided s_server and s_client (in the apps
> directory) under the default SSL version, the client will wait for
> more inputs after receiving a renegotiation request from the server
> (sent by s_server when we enter "R" from stdin). If the server does
> not send any data through the SSL link after renegotiation, then the
> client blocks: it can neither read from stdin nor send any data out.
> Reason: I traced the problem to ssl3_read_bytes, after renegotiation
> (line 712 of s3_pkt.c), if the renegotiation is successful, the
> program will go back to "start:", which waits for more packets from
> the peer. I think this is problematic. I don't see any requirement
> that force the server to send more data after renegotiation.
This is actually a problem of s_client, not of the SSL library.
SSL_read is supposed to work that way -- s_client asks for data, so
the library waits until some is available. If this is not the desired
behaviour, then one should use non-blocking I/O; for s_client this
means, use the -nbio option. Blocking I/O is not suitable for
full-duplex communication.
> =========================================================
> BUG2: memory problem in $(OPENSSL)/crypto/bio/b_sock.c:283
>
> j=strlen(a->h_name)+1;
> if ((ret->h_name=Malloc(j)) == NULL) goto err;
> ===> memcpy((char *)ret->h_name,a->h_name,j+1);
> for (i=0; a->h_aliases[i] != NULL; i++)
> {
> j=strlen(a->h_aliases[i])+1;
> if ((ret->h_aliases[i]=Malloc(j)) == NULL) goto err;
> ===> memcpy(ret->h_aliases[i],a->h_aliases[i],j+1);
> }
> Comment: j+1 should be replaced by j. Note that only j bytes are
> allocated
> using "Malloc", and j has already included the trailing '\0' of the
> string.
You're right; I have now repaired it.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
