[RADIATOR] AuthBy DUO issue

Alexander.Hartmaier at t-systems.com Alexander.Hartmaier at t-systems.com
Tue Jun 8 12:06:26 UTC 2021


Von: radiator <radiator-bounces at lists.open.com.au> im Auftrag von Heikki Vatiainen <hvn at open.com.au>
Gesendet: Mittwoch, 2. Juni 2021 17:01
An: radiator at lists.open.com.au <radiator at lists.open.com.au>
Betreff: Re: [RADIATOR] AuthBy DUO issue

On 1.6.2021 19.23, Alexander.Hartmaier at t-systems.com 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20210608/f6cda0fc/attachment.html>


More information about the radiator mailing list