[RADIATOR] AuthBy DUO issue

Heikki Vatiainen hvn at open.com.au
Wed Jun 2 15:01:03 UTC 2021

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.

> 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.


> [1] 
> https://metacpan.org/release/HTTP-Async/source/lib/HTTP/Async.pm#L551 


Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.

More information about the radiator mailing list