> David
>
> can't understand
> ""Incorrect. The 'SSL_write' function is the function to send
> unencrypted data over the SSL link. It has nothing to do with the
> encrypted data the SSL engine wants to write to the socket.""
> When we do SSL_write the i/p is unencrypted data and this gets send
> over the SSL link.
It may or may not get sent immediately though. The SSL engine may need
to
receive something before it can send it. The point is, SSL_write takes
plaintext. The SSL engine then does whatever it needs to do to get that to
the other side, which might or might not involve writing to the socket right
now.
> I do agree the API as such is not encrpyting the
> data but it in turn calls the engine API to do the same and thus in a
> way it is doing encrpytion..
> Please let me know what I am missing?..
Let's go back. This is correct.
> > > If you get SSL_ERROR_WANT_WRITE, even if you have no application data
> > > to send, the protocol itself requires data to be written
> >
> > Correct.
But this is incorrect:
> > > -- so you
> > > need to call SSL_write().
Because:
> Incorrect. The 'SSL_write' function is the function to
> send unencrypted data over the SSL link. It has nothing to do
> with the encrypted data the SSL engine wants to write to the socket.
This is incorrect:
> > > If you get SSL_ERROR_WANT_READ, even if
> > > you're writing application data, that means that the protocol itself
> > > is requiring data to be read from the peer, so you need to call
> > > SSL_read().
Because:
> > No. If the protocol itself needs to read data from the
> peer in order to write data, it will do so when you call
> SSL_write. The job of SSL_write is to do whatever is needed to
> encrypt and send the data you are writing, whether that means
> reading from the socket, writing to the socket, or both.
> >
> > > Both situations can happen in either case. If you have no data to
> > > write, call it with a NULL buffer and a length of 0.
This is incorrect:
> > No. Do not ever do that. If you have no data to write,
> do not call SSL_write.
Because:
> > This is based on the most grievous misunderstanding of
> what the SSL_read and SSL_write functions do. They do *NOT* read
> from and write to the socket. They read from and write to the
> logical SSL connection. That may require reading from the socket,
> writing to the socket, or both in any combination, and your
> program should not make assumptions about which and when.
I'm not sure how I can make it any clearer. You call SSL_read when you
want
to see if the SSL engine has any plaintext for you. It has nothing to do
with receiving encrypted data from the socket, as far as the application is
concerned. You call SSL_write when you want hand some plaintext to the SSL
engine to get to the other side.
A call to SSL_read might resulting in reading from the socket, writing
to
the socket, neither, or both. A call to SSL_write might result in writing to
the socket, reading from the socket, neither, or both.
It is a serious mistake to try to teach your application SSL. Let the
SSL
engine do that. If the SSL engine returns 'WANT_READ' that means it could
not complete the operation you attempted without blocking because it needs
to read some data from the other side. The operation could be an SSL_read or
an SSL_write, it doesn't matter, that's the operation that couldn't
complete. This doesn't mean you should call SSL_read -- you should call
SSL_read if you want to read *plaintext*. WANT_READ means it wants to read
more protocol or encrypted stuff.
Similarly, if you call SSL_read and get a WANT_WRITE indication, this
means
the SSL engine needs to write to the socket before it can give you any more
plaintext. This means you should 'select' for writability and then retry the
operation by calling SSL_read again.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
