Re: [openssl-users] SSL_read, SSL_write error handling
I did find a very good explanation here:
https://mta.openssl.org/pipermail/openssl-users/2015-March/000709.html
The idea of "what SSL wants" and "what the app wants" is a very good
explanation. This is the pseudocode I'm working with currently:
io_callback(events) {
if (messages_to_send && (events & OS_WRITABLE)) {
SSL_write(.);
if (error) {
if (error_is_want_read) {
system_poll &= OS_READABLE;
} else if (error_is_want_write) {
system_poll &= OS_WRITABLE;
}
update_os_poll(system_poll);
return;
} else {
// emit send success to app
}
} else if (app_wants_data && (events & OS_READABLE)) {
SSL_read(.);
if (error) {
if (error_is_want_read) {
system_poll &= OS_READABLE;
} else if (error_is_want_write) {
system_poll &= OS_WRITABLE;
}
update_os_poll(system_poll);
return;
} else {
// emit the data to app
}
}
}
This code is probably not 100% correct, but should show my design pretty
clear. One needs to do what YOU want, combined with what SSL wants.
However, question still remains - it is ALLOWED to perform SSL_read before
SSL_write, when a previous call to SSL_write failed with WANT_READ?
2016-09-15 7:01 GMT+02:00 Viktor Dukhovni <openssl-us...@dukhovni.org>:
> On Thu, Sep 15, 2016 at 05:07:22AM +0200, Alex Hultman wrote:
>
> > If SSL_write returns the error SSL_ERROR_WANT_READ, am I then allowed to
> > call SSL_read before I have called SSL_write?
>
> WANT_READ means that OpenSSL *internally* needs to read some (often
> ciphertext) bytes from the peer, and that since the socket is
> non-blocking or you're using BIO_pairs, ... the application must
> wait for data to arrive (poll(), select(), ...) and then retry
> the call once the socket becomes readable.
>
> It is not an invitation to read *application* layer data, which
> would typically also fail for lack anything to read at that
> moment.
>
> * WANT_READ -- Select the socket for read, and retry
> the original function (hanshake, read or write) once
> the socket is readable.
>
> * WANT_READ -- Select the socket for write, and retry
> the original function (hanshake, read or write) once
> the socket becomes writable.
>
> Again, these are not a request for the application to *consume*
> data, rather the application needs to retry once the socket is
> ready for the requested operation. OpenSSL will internally
> read or write to the socket.
>
> --
> Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] SSL_read, SSL_write error handling
If SSL_write returns the error SSL_ERROR_WANT_READ, am I then allowed to call SSL_read before I have called SSL_write? What I'm trying to figure out is, can I handle SSL_ERROR_WANT_READ with one or many calls to SSL_read, and can I handle SSL_ERROR_WANT_WRITE with one or many calls to SSL_write - despite the fact that the error was thrown by the opposite SSL_* function call? Does an SSL_ERROR_WANT_READ have to be handled by the SSL_* function that caused the error, or will any of the two (SSL_read, SSL_write) functions handle this desire? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [Bug] OpenSSL does not send short messages
Yes you are correct. I'm doing things wrong - it seems to be Chrome and Curl that report "no received data" because it actually does work in Firefox. Well, thanks for taking the time. 2016-04-26 7:05 GMT+02:00 Alex Hultman <alexhult...@gmail.com>: > Yes you are correct. I'm doing things wrong - it seems to be Chrome and > Curl that report "no received data" because it actually does work in > Firefox. Well, thanks for taking the time. > > 2016-04-26 6:55 GMT+02:00 Viktor Dukhovni <openssl-us...@dukhovni.org>: > >> [ This question belongs on openssl-users, not openssl-dev. Please >> reply only to openssl-users. ] >> >> On Tue, Apr 26, 2016 at 05:17:46AM +0200, Alex Hultman wrote: >> >> > SSL_write followed by SSL_shutdown does not actually send the data >> passed >> > to SSL_write if the total data size sent is less than (on my system) 7-8 >> > bytes. >> >> This does not happen in "openssl s_client". You're likely doing >> something wrong. >> >> In one window I start an openssl server: >> >> $ cipher=ADH-DES-CBC3-SHA >> $ seclev= # Make that seclev=":@SECLEVEL=0" with OpenSSL 1.1.0 or >> later >> $ openssl s_server -quiet -cipher "$cipher$seclev" -nocert -accept >> 12345 >> >> I another window I start a client: >> >> $ cipher=ADH-DES-CBC3-SHA >> $ seclev= # Make that seclev=":@SECLEVEL=0" with OpenSSL 1.1.0 or >> later >> echo XXX | openssl s_client -debug -no_ign_eof -cipher >> "$cipher$seclev" -connect localhost:12345 >> >> On the server side I see the expected output: >> >> XXX >> >> On the client side after lots of handshake messages: >> >> >>> ??? [length 0005] >> 17 03 03 00 24 >> write to 0x7f7f8bd003d0 [0x7f7f8c80b203] (41 bytes => 41 (0x29)) >> - 17 03 03 00 24 c2 19 ea-c6 f1 a8 c7 74 31 50 3d >> $...t1P= >> 0010 - a1 2f fb f0 d5 4d 2e 85-e0 6a 18 86 27 6a 09 1d >> ./...M...j..'j.. >> 0020 - de 98 4e 69 05 57 0f 4c-93..Ni.W.L. >> DONE >> >>> ??? [length 0005] >> 15 03 03 00 24 >> write to 0x7f7f8bd003d0 [0x7f7f8c80b203] (41 bytes => 41 (0x29)) >> - 15 03 03 00 24 d2 94 f8-11 dd 69 81 f7 ab cc 8c >> $.i. >> 0010 - c4 13 4c 80 24 d7 50 10-b9 62 74 d7 21 86 16 78 >> ..L.$.P..bt.!..x >> 0020 - b4 83 87 da 5e 2f d9 5d-34^/.]4 >> >>> TLS 1.2Alert [length 0002], warning close_notify >> 01 00 >> >> The first of these is the "XXX" encrypted to 16 bytes, and padded >> with a 20-byte SHA1 MAC (the server and client negotiated TLS 1.2 >> with Encrypt-then-Mac). The second is the encrypted shutdown alert. >> >> > Is this known behavior? >> >> No. >> >> -- >> Viktor. >> > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
