> I have a client that attempts to open a secured session with the server.
> After calling SSL_connect(), on failure, the client would free the SSL
object,
> and read the response on normal tcp socket.
> On the other hand, the server calls SSL_accept(), and on failure, would
free
> the SSL object, and return the error message to the client on normal tcp
socket.
> But what I see is, the client receives some 9 bytes of data after
SSL_connect fails.
> This data seems to be SSL control data, as it reaches the client even
before the
> server actually sends out the error message. The 9 bytes are
> (16 03 00 00 04 0e 00 00 00).
How could you ensure that both the server and the client fail at precisely
the same point? That would seem to be nearly impossible.
> Here is the code snippet from the client code that is in trouble,
> and receives these 9 bytes. the value returned in beresp is the first
> byte of these 9.
> Am I missing something while handling SSL_connect failures?
> ===================================================
> if ( SSL_connect(sock->ssl) != 1 ) {
> printf("\t%s'", ERR_reason_error_string(ERR_get_error()));
> SSL_free(sock->ssl);
> ssl = NULL;
> }
> else
> secured = 1;
> }
> beresp = get_char(sock);
This is complete nonsense. Since SSL_connect returned an error, that means
it read something it didn't like. Since it didn't understand what the other
side sent, how can it ensure it read all of it?
> Please let me know if I can provide any more information that might be of
help
> to understand the scenario
The scenario seems to require the impossible in several regards. First,
SSL_connect must somehow be careful not to read the plaintext failure
message. But how can it do this? Second, SSL_connect must be sure to read
all the non-plaintext when it fails to understand what's going on. But how
can it do this?
Your scheme doesn't seem to make any sense at all. You can't ensure a
failure will be perfect.
You can probably make this work 99% of the time with extreme ugliness if
it's an absolute requirement. Have the server send the message, sleep a
second or two, send it again, and so on. Use unique byte codes to mark the
beginning and the end of the message. The client must carefully scan the
stream paying attention only to the data in-between the start and end
markers.
This should ensure the other end fails eventually, and when it does, it
won't matter if there's leftover SSL stuff or some of the message was eaten.
Eventually, it will find the beginning and end of the error message.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
