> 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.
Do you have any rational basis for this belief? Consider: 1) The client calls SSL_connect. A TCP connection forms. 2) The client sends negotiation data. 3) The server reads the negotiation data, doesn't like it and sends an SSL abort to the other side. SSL_accept returns an error. 4) The server sends a plaintext error message. 5) The client calls 'read' from SSL_connect, reading both the negotiation data and the plaintext error. > 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. Nonsense. SSL_connect calls 'read' for an arbitrarily large number of bytes. It accepts the possibility that it might read past a single SSL record or protocol data unit. > 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. Except that the server has already sent the error message. The client has already called 'read' (from SSL_connect). > 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. Since it shouldn't work, it's hardly surprising that it doesn't work. > 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. I explained the necessary logic. After the server detects failure, it must send the error message several times, with a uniquely identifiable separator around the error message. The client must scan the data stream until it finds the separators and extracts the error message from therein. You may need to wait a bit to make sure the client has gotten a chance to call 'read', otherwise all your transmissions of the error message may single coalesce into a single 'read' that's done by SSL_connect. If you know how big the SSL_connect buffer is, you can send twice that many zero bytes before the error to ensure SSL_connect can't eat them. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
