HostAPd 2.6 fails EAP authentication with OpenSSL 1.1

[Alan DeKok]

On Oct 30, 2017, at 6:06 AM, Jouni Malinen <j at w1.fi> wrote:
> That talks about Debian OpenSSL package disallowing use of TLS v1.0. In
> other words, this sounds like a security policy choice and expected
> behavior to reject a client that does not support enabled protocol
> versions.

  It was a "security" choice by Debian to remove TLS v1.0 from *all of Debian*.

> Please note that OpenSSL 1.1.0f itself does support TLS v1.0
> and when built with default options, v1.0 seems to be enabled as well.

  Yes.

>> The solution was to use SSL_CTX_set_max_proto_version and
>> SSL_CTX_set_min_proto_version as you can see on
>> https://github.com/FreeRADIUS/freeradius-server/commits/v3.0.x/src/main/tls.c
>> (anything on or after September 8 2017).
> 
> I'm not sure I'd call that a solution.. At best, that sounds like a
> workaround that explicitly ignored distro security policy for TLS.

  Application authors using TLS in Debian complained.  All of them.

  Debian changed their policy so that apps using the "old" OpenSSL APIs would get TLS v1.0 disabled by default.  This meant that old applications would, by default, be "secure".

  i.e.  SSL_CTX_set_min_proto_version() was added by Debian, as a concession that sometimes application developers do know how to do security.

> You
> cannot both have a policy that mandates TLS v1.0 to be disabled for
> everything in the system and have client devices that do not support
> anything else than TLS v1.0.

  Debian changed their policy.  TLS v1.0 is disabled by default, but applications can explicitly enable it.  I've done that in FreeRADIUS, because allowing TLS v1.0 is required for real-world environments.

  As has been noted in the IETF recently, there are ~2 billion devices running EAP.  Mandating that they upgrade is just a non-starter.  People who try to enact such mandates don't understand the consequences of their actions.

  Alan DeKok.