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
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-users at 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.
>
> --
> Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
Regards,
Ajay
