On 10 Oct 2015, at 14:40, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On 10 Oct 2015, at 08:57, Alan DeKok <aland@deployingradius.com> wrote:
OpenSSL 1.0.2 changes the way it interacts with FreeRADIUS. None of this is documented by OpenSSL. The result is that instead of successful authentication, you get:
(6) eap_ttls: ERROR: Invalid ACK received: 256 (6) eap_ttls: ERROR: [eaptls verify] = invalid (6) eap_ttls: ERROR: [eaptls process] = invalid
The only solution is to apply the patch in commit b7b5493c61. It doesn't fix the underlying OpenSSL problem, but it makes FreeRADIUS ignore the broken API calls.
This problem is serious enough that we may have to issue 3.0.11, and possibly 2.2.10, also.
Have to draw a line on 2.2.x this uncertainty undermines people making the case to move to v3.0.x. 1.0.2 is not included by default in any stable releases of FreeBSD, Ubuntu/Debian, Redhat/Centos, OSX.
We experienced it because homebrew has moved to OpenSSL 1.0.2.
Which exact version of OpenSSL 1.0.2?
I'm asking because I'm running FreeRADIUS 3.0.10 (formerly 3.0.9) on openSUSE Tumbleweed (x86_64 and armv6l) with package openssl-1.0.2d-1.1 using EAP-TTLS/PAP without issue.
TTLS PAP works because we don't ACK the last TLS fragment sent by the supplicant, we just fudge an EAP-Success. Or at least that's what it appears is happening. I'm not sure if this is the correct behaviour. It's on a todo list of EAP-TLS things to investigate, along with sending the correct TLS Alert record on authentication failure. If you try TTLS-MSCHAPv2 you'll see a failure. If you wanted to do something useful, you could try the different TLS based EAP methods and figure out which ones are definitely broken. The code path is common for all EAP-TLS based methods, so the assumption is that many will be broken by this.
Maybe you're hitting the HMAC ABI incompatibility? It was fixed in 1.0.2c: https://www.openssl.org/news/changelog.html#x2
This was with 1.0.2d, so no. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2