[RADIATOR] AuthBy DUO issue
hvn at open.com.au
Fri Jun 11 11:42:01 UTC 2021
On 8.6.2021 15.06, Alexander.Hartmaier at t-systems.com wrote:
>> I think this is a good explanation what I think might be happening with
>>  below.
> That makes sense!
> But when OpenSSL receives and reads that data, shouldn't the socket stop
> reporting available data?
I'd say what happens is that when the module reads the socket and
OpenSSL machinery is rotated consuming all input from the socket, there
is no user data left and read for user data does not return until some
is left. That would be when a response comes from DUO. Or something
similar is happening. I think OpenSSL does not support returning zero
It's not doing a busy loop trying to read the socket, so it seems to
It might be that the assumption in the module is that when a socket is
readable after TLS handshake, it means that there's data or the
connection was closed. It may not be prepared for nothing but a
Caution: I haven't yet looked into this in detail.
> What is your plan to fix this issue?
One option is to select only TLSv1.2 by default and make it
configurable. If the problem is with Net::HTTPS::NB or HTTP::Async,
allow by default TLSv1.3 when a working version of this/those is detected.
> Will you provide a patch for HTTP::Async or migrate AuthDUO.pm to for
> example AuthREST.pm?
HTTP::Async and/or Net::HTTPS::NB would need a fix for current
installations. The AuthREST.pm, actually DUO AuthBy built on top of
HTTPClient.pm is something we have considered too. We now have HTTP
client support for exactly these kinds of things.
Thanks again for following up on how it goes now.
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