To begin with, when the client calls SSL_connect(), it is guaranteed that
the server is waiting / looping in SSL_accept(). So I believe there is no
chance that SSL_connect() will read any plaintext data.
In my scenario, the ERR_reason_error_string(ERR_get_error()) tells me that
there was a problem in server certificate verification. Also on the server
side, SSL_accept reports 'SSL alert number 42'. In this case the
SSL_connect() failed because it knew what was wrong, not because it didn't
understand what the server had sent. Now as this failure is a result of SSL
handshake, and as the reason of the failure is knows to the client,
SSL_connect should have clean all the data sent by the server as part of SSL
handshake. The tcp channel should have been cleaned before SSL_connect()
returned.
Now when the SSL_connect() fails (and it would imply that corresponding
SSL_accept would have also failed), the client knows that the server is
going to send the error message back to the client in plain text. So the
client reads next packet in plain text.
Allow me to explain what I see on the client-server communication (The
server is using non blocking sockets)
The first call of SSL_accept() return WANT_READ
The client initiates SSL_connect()
As we detect readability, we call SSL_accept(), which now return WANT_WRITE
(I guess this is the data that reached me after SSL_connect returned).
By this time, the client SSL_connect() has already returned with -1.
The client assumes that the next data that would come would be plain text
error message sent by the server. And this is where it fails.
I will be glad if you could give me a sample code snippet that will show how
one can handle SSL_connect / SSL_accept failures correctly and gracefully.
Thank you for all the help.
~ Urjit
----- Original Message -----
From: "David Schwartz" <[EMAIL PROTECTED]>
To: <openssl-users@openssl.org>
Sent: Friday, December 14, 2007 7:48 PM
Subject: RE: Problem in handling SSL_connect failures
>
>
> > 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]
>
DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the
property of Persistent Systems Ltd. It is intended only for the use of the
individual or entity to which it is addressed. If you are not the intended
recipient, you are not authorized to read, retain, copy, print, distribute or
use this message. If you have received this communication in error, please
notify the sender and delete all copies of this message. Persistent Systems
Ltd. does not accept any liability for virus infected mails.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
