[openssl-users] Root-Level queries while using SSL-connections wrapping "sockets"
ajaygargnsit at gmail.com
Sun Oct 9 14:47:18 UTC 2016
On Fri, Oct 7, 2016 at 11:17 PM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
> On Fri, Oct 07, 2016 at 10:30:06PM +0530, Ajay Garg wrote:
>> Ok, so for sending app-payload-bytes, we do a bio_write() to "bio1",
>> and if "bio1" requires reading from bio2/peer, bio_write() will return
>> SSL_ERROR_WANT_READ (even for blocking sockets). We then read-in some
>> app-payload-encrypted-bytes from device-socket,
> No, it will *usually* return SSL_ERROR_WANT_WRITE, that's when you
> write "some" (based on pending data amount from bio2) to the network
> that you read from bio2. Those writes might be written via a buffer
> you interpose, however it is important to flush that buffer as
> much as possible before attempting any network reads (flush fully
> if the network reads are potentially blocking).
> However, it might sometimes return SSL_ERROR_WANT_READ, in which
> case, the SSL layer wants to read, even though the application
> wants to write. Your job is to do the read on the SSL layer's
> behalf, and then retry the write.
For this particular sub-case, let's say SSL-layer wants to obtain "n"
bytes from the socket/wire.
So, in this case, is it ok to do a blocking-read on the socket, unless
"n" bytes are received (of course, a socket "error" will be handled in
the blocking-call; it's just that any socket-timeouts will not be
I hope the following is NOT happening internally ::
SSL-layer "advertises" that it wants "n" bytes from socket/wire.
However, in reality, it first wants "x" bytes from socket/wire, then
actually wants to send "m" bytes, and then finally wants to receive
the remaining "n-x" bytes from socket/wire.
I am sure it is not happening, just want to confirm :)
> Where "some" is obtained by queried bio2 for the amount of pending
> data. You can loop reading/sending smaller amounts that if the
> entire amount is too big to write to the target in one go without
> blocking. Otherwise, you need a large enough write buffer downstream.
> If you can't fully drain bio2's output in one go, just keep the
> socket selected for write and try again later when more space is
>> put them into "bio2"
>> (thus internally fulfilling bio1's need for read), and then again try
>> bio_write() to "bio1" WITH IDENTICAL APP-PAYLOAD-BYTES. If it again
>> returns SSL_ERROR_WANT_READ, we repeat the cycle.
> Well, you may not fulfill that need, if you don't drain all the
> pending data, and so the SSL_ERROR_WANT_... may repeat. What you
> do with bio2 has no direct relationship on the direction of the
> I/O in bio1. Just keep track of whether the crypto wants to read
> or write, and whether either bio2 or any buffer you interpose
> downstream has pending data. Then move data between the network
> and bio2 as appropriate.
>> For reading app-payload-bytes, we do a bio_read() from "bio1", and if
>> "bio1" requires writing bytes to bio2/peer, bio_read() will return
>> SSL_ERROR_WANT_WRITE (even for blocking sockets).
> No, it will *usually* return SSL_ERROR_WANT_READ, that's when you
> read "some" (based on desired read size from bio2) from the network
> and write the results to bio2. Those reads might be satisfied from
> a buffer you interpose.
> However, it might sometimes return SSL_ERROR_WANT_WRITE, in which
> case, the SSL layer wants to write, even though the application wants
> to read. Your job is to do the write on the SSL layer's behalf,
> and then retry the read.
>> We then pick up the
>> app-payload-encrypted-bytes from "bio2", transfer them over the wire
>> via device-specific-socket (thus fulfilling bio1's need to send bytes
>> to peer), and then again try bio_read() from "bio1" WITH IDENTICAL
>> APP-PAYLOAD-BYTES. If it again returns SSL_ERROR_WANT_WRITE, we repeat
>> the cycle.
> When retrying app-layer reads, you do not need to provide the same
> buffer or read request size on subsequent attempts.
>> Obviously, for the above two sub-plots, the only chance of failure if
>> reading/writing bytes fails over the wire.
>> But that is not the norm; if it does happen, then everything will be
>> restarted from scratch (at least by me).
>> If yes, then it seems everything can be done fully synchronously for
> No, synchronous operation will not work. The network may not be
> ready to receive more data when you're ready to write (network
> layer data), or have more data when you're ready to read. Use of
> bio-pairs with blocking sockets is highly risky, you'll probably
> dead-lock with some regularity.
>> thus eliminating the need of multiple threads,
> You don't need threads, an event loop will do. Indeed an event
> loop is generally better, don't know whether the same bio-pair is
> safe for use by multiple threads.
> You just need to be able to perform the equivalent of
> on whatever interface you have for moving data to/from
> the network.
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
More information about the openssl-users