[openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"

[Ajay Garg]

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