On 07/10/2016 16:35, Ajay Garg wrote:
Hi Viktor.

Thanks for your reply, and I am sorry for being idiotic, OpenSSL does
seem daunting, but I am learning :)

Also, let's not bother too much about the APIs/methods as such.
I will be grateful if you could confirm/reject my
architectural-understanding so far.

Let's say "bio1" is the SSL-BIO, and "bio2" is the In-Memory-BIO, and
they have been made a pair, with the architecture being ::

App <=> bio1 <=> bio2 <=> device-specific-socket

One caveat for both scenarios below:

RW2a: During step R2 or W2, the SSL/TLS protocol may need to
transmit some data in the opposite direction in order to handle
automatically setting or changing the encryption keys etc.  Thus
during W2, some data may be read from bio2 and during R2, some
data may be written to bio2.

This doesn't happen every time, but it always happens for the
first app-payload-bytes, and it may happen at any later time
subject to changes as the protocol and/or library are improved.

So, for writes, following steps can be made to happen synchronously
(even with blocking device-specific-sockets) ::

    W1. App writes x app-payload-bytes to bio1.

    W2. Internally, x app-payload-bytes (at bio1) become y
app-payload-encrypted-bytes (at bio2).

    W3. Thereafter, the y app-payload-encrypted-bytes are transferred
over the wire via the device-specific-socket.

I think W2 is the key-step architecturally.


For reads, following steps can be made to happen synchronously (even
with blocking device-specific-sockets, carrying read-timeout feature)
::

   R1. App wants x app-payload-bytes.

   R2. If bio1 can produce at least x app-payload-bytes, then we are done.

         Else, we read some (let's say n) app-payload-encrypted-bytes
from device-specific-socket, write them into bio2, and
         again enquire if bio1 can now produce at least x app-payload-bytes.

         If still not, we keep reading n app-payload-encrypted-bytes
from device-specific-socket and writing them into bio2, until
         bio1 can produce at least x app-payload-bytes.

   R3. Finally, App reads x app-payload-bytes.

Here too, I think R2 is the key-step architecturally.



Is my above architectural-understanding of the workflow between App
and Device-Specific-Socket correct?


Anyway, thanks for your help so far.


Thanks and Regards,
Ajay




On Fri, Oct 7, 2016 at 3:25 PM, Viktor Dukhovni
<openssl-us...@dukhovni.org> wrote:
On Fri, Oct 07, 2016 at 12:28:46PM +0530, Ajay Garg wrote:

I realise I am still stuck with the original issue.
Failure to read the documentation closely.

Also, how do "bio1" and "bio2" communicate in case of non-ideal
scenarios (timeouts, errors)?
They don't, you move all the data.  All reads/writes by OpenSSL will
return SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE when the requisite
data is not already buffered.  At that point you do the requsite
I/O and copy data into and out of the network bio.

First, do all pending writes:

     BIO_ctrl_pending(network_bio)
     BIO_read(network_bio, ...)

     ... write the opaque ciphertext to the underlying socket-like
     ... thing when it is writable, take to not block or drop
     ... the ciphertext on the floor if you do.

then if SSL_ERROR_WANT_READ, find out how much OpenSSL wants to
read, and read that much data from the underlying socket-like thing
and copy its (opaque ciphertext) into the network bio:

     BIO_ctrl_get_read_request(network_bio)
     BIO_write(network_bio, ...)

A double-buffer (separate read/write) between the socket and SSL
may make the logic simpler, but the write side must be flushed
whenever to the SSL network BIO becomes empty, to avoid deadlock.
And of course avoid blocking on reads when it is OpenSSL's turn to
write.  In general you have an event loop, a non-blocking socket
thingy, and select/poll/... read/write or both depending on
SSL_ERROR_WANT_READ/WRITE and the state of any intermediate buffers
you're managing.

A careful read of the manpage will expose all these facilities.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to