[RADIATOR] SSL3_GET_RECORD:wrong version number

[Heikki Vatiainen]

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