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 : > 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 : > 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 : > >> [ 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