On 19.4.2022 21.47, Ullfig, Roberto Alfredo wrote:
Hello, we've been getting these errors for months, maybe longer:
SSL3_GET_RECORD:wrong version number
a few hundred a day out of 500K logins. They happen on a development
Radius server as well by a login from a monitoring account.
That account logged in 490 times today and the login failed once:
AuthFILE PEAP TLS Handshake error: result: -1, reason/error:
'SSL_ERROR_SSL', state: 'error', error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number
This happens very early when OpenSSL library parses incoming TLS. Before
this error can happen with TLS-based EAP methods, the user has started
EAP authentication successfully, but during the EAP authentication a
message is received that can't be parsed.
Possible reasons include: client attempting use a TLS version server
does not support, corrupted messages, bad client implementation where
client says that it uses PEAP but does not send TLS when it should.
TLS messages, or more exactly a sequence of TLS records, start with
version number. The above error message could mean that a record in the
incoming TLS message is completely corrupted so that even the version
number completely off.
With OpenSSL, at least some vesrions, a possibility is that client
attempts to use TLS version that is higher than server supports. For
example, server supports TLSv1.0 and client uses TLSv1.2. If this is
reversed, server support TLSv1.2 and client supports TLSv1.0 the the
message seems to be 'unknown protocol'.
If version is slightly off, for example TLSv1.2 is attempted with an old
server that knows only TLSv1.0, then this gets logged as 'unknown
protocol' too.
The above are likely to depend on the OpenSSL version, but I'd say the
main thing is that 'wrong version number' can mean corrupted messages in
addition to server and client not supporting the same TLS versions.
On the development server, the login is always from the same Raspberry
Pi. It does go through an F5 load balancer but there's just one member
Radius server/port involved.
Any idea why 1 out of 490 logins fail from an automated monitor?
I'd say the reasons are similar than with PEAP. With TLS over TCP in
Radiator, OpenSSL is used similarly than with TLS-based EAPs.
You can trigger similar error with telnet by connecting to TLS-protected
monitor port and then typing 'asdf' and hitting enter. OpenSSL tries to
detect plain HTTP attempts and logs those as 'http request' errors.
If possible, see if wireshark can tell more about what happens with the
Pi and Radiator.
To summarise: the problem with Raspberry Pi is more unexpected than PEAP
errors. From what I have seen there are typically some number of errors
seen with busy TLS-based EAP servers.
Thanks,
Heikki
--
Heikki Vatiainen
OSC, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software
_______________________________________________
radiator mailing list
[email protected]
https://lists.open.com.au/mailman/listinfo/radiator
