[openssl-users] SSL_read() returns -1, and SSL_read_ex does not update readbytes where a record containing a session ticket is being read (TLS 1.3)

[Matt Caswell]

On 23/01/2019 14:04, Arran Cudbard-Bell wrote:
> I'm working with wpa_supplicant to try and fix up its EAP-TTLS and EAP-PEAP
> implementations to work correctly with TLS 1.3 and session tickets.
> 
> Where a new_session_ticket message is sent after client/server finish, calls
> to SSL_read() result in the new_session_ticket message being processed
> correctly, but SSL_read() returns -1 if no application_data is available in
> the input BIO. SSL_read_ex() returns 0, but readbytes isn't updated to
> reflect the number of bytes consumed whilst processing the session tickets.

This is intended behaviour. SSL_read() returns the number of plaintext
application data bytes that have been populated in the provided buffer
(similarly for readbytes). If no application data is available then you get the
-1 (for SSL_read()) or 0 (for SSL_read_ex()) return code. You also get that
return code for other types of issues, and you are supposed to call
SSL_get_error() to interpret it.

Note that by default OpenSSL sets SSL_MODE_AUTO_RETRY in 1.1.1 (which it didn't
in 1.1.0). This should mean that it automatically tries again to read
application data without returning an error. Have you switched
SSL_MODE_AUTO_RETRY off?

> 
> It seems to be that SSL_read() should return a positive integer representing
> the number of bytes read from the BIO whilst processing the session tickets,
> and SSL_read_ex should update readbytes to the number of bytes read from the
> BIO whilst processing the session tickets, as is done with other handshake
> messages.

This is not correct. SSL_read()/SSL_read_ex() only ever provide the number of
application data bytes that have been read, irrespective of how many bytes were
read from the underlying BIO.


Matt