[RADIATOR] AuthBy DUO issue
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 .
> Is that correct?
That's my hunch too. That is, I did not verify it throughly but it
> 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
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,
EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.
More information about the radiator