On Thu, Jan 24, 2019 at 11:09:40PM +0700, Arran Cudbard-Bell wrote:
> We could use this to determine what SSL_ERROR_WANT_READ is indicating. As it
> seems SSL_ERROR_WANT_READ could indicate two conditions in this scenario:
>
> 1) No pending bytes - Additional handshake messages were processed,
>> 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.
>
> In this case SSL_get_error() returns 2
> 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
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()
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
