Von: radiator <[email protected]> im Auftrag von Heikki Vatiainen <[email protected]> Gesendet: Mittwoch, 2. Juni 2021 17:01 An: [email protected] <[email protected]> Betreff: Re: [RADIATOR] AuthBy DUO issue
On 1.6.2021 19.23, [email protected] wrote: > today at noon I had the change to reenable Cisco Duo and set TLS to v1.2. > So far it looks good, I saw other authentication requests getting > processed while AuthBy DUO waited for a user response. Thanks for the update. Please keep us posted if the situation changes. So far the TLSv1.2 workaround works. > I haven't grapsed so far how TLSv1.3 could cause this bug? > If I understood it correctly, the underlying socket reports available > data via select although none has been received so far [1]. > Is that correct? That's my hunch too. That is, I did not verify it throughly but it looked familiar. > How does the TLS version influence that? TLSv1.3 is much different from SSL3.0 - TLSv1.2. One major difference is the way session resumption works with TLSv1.3. With the other versions, information needed for resumption was communicated between the peers during the TLS handshake. With TLSv1.3 the handshake complets first and then the optional resumption information (Pre-Shared Keys) are sent by the server. The main thing is that it's now normal to receive non-data records after handshake has finished. With TLSv1.3, when the the socket indicates it's readable, there's no userdata and the read blocks. It does update the session's internal state and ability to resume, though. I think this is a good explanation what I think might be happening with [1] below. https://wiki.openssl.org/index.php/TLS1.3#Non-application_data_records That makes sense! But when OpenSSL receives and reads that data, shouldn't the socket stop reporting available data? What is your plan to fix this issue? Will you provide a patch for HTTP::Async or migrate AuthDUO.pm to for example AuthREST.pm? > [1] > https://metacpan.org/release/HTTP-Async/source/lib/HTTP/Async.pm#L551 Thanks, Heikki Thanks, Alex
_______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
