Warnings about OpenSSL 1.0.1f and 1.0.1g
Anyone using these versions of OpenSSL should either upgrade them, or set "disable_tlsv1_2" in the EAP TLS module configuration. To make a long story short, these versions of OpenSSL calculate the WiFi encryption keys incorrectly for TLS 1.2. I've pushed a fix to v3.0 which disables TLS 1.2 when the server is built against those versions of OpenSSL. The solution is to upgrade to a version of OpenSSL which works, upgrade FreeRADIUS, or to use "disable_tlsv1_2" on existing systems. Alan DeKok.
On 11 Dec 2015, at 09:17, Alan DeKok <aland@deployingradius.com> wrote:
Anyone using these versions of OpenSSL should either upgrade them, or set "disable_tlsv1_2" in the EAP TLS module configuration.
To make a long story short, these versions of OpenSSL calculate the WiFi encryption keys incorrectly for TLS 1.2. I've pushed a fix to v3.0 which disables TLS 1.2 when the server is built against those versions of OpenSSL.
The solution is to upgrade to a version of OpenSSL which works, upgrade FreeRADIUS, or to use "disable_tlsv1_2" on existing systems.
There's a stripped down version of the centos OpenSSL 1.0.1 spec files in v3.1.x and i've modified the freeradius spec files to build against them if '--with freeradius-openssl' is passed to rpmbuild. Should work ok for Centos/RHEL7, not tested on 6. The OpenSSL problems aren't getting any better, and OS vendors lag behind the latest version massively. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 12 Dec 2015, at 15:37, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Should work ok for Centos/RHEL7, not tested on 6. The OpenSSL problems aren't getting any better, and OS vendors lag behind the latest version massively.
CentOS 7.2 is using OpenSSL 1.0.1e out of the box so *should* be unaffected... Is there a test for this issue (in the test suite or with eapol_test/radtest etc.) so I can make sure RedHat haven't helpfully backported the bug? Regards, Adam Bishop gpg: 0x6609D460 jisc.ac.uk | Networkshop 44: Save the date! | 22-24 March 2016 @ University of Manchester Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
On Dec 14, 2015, at 8:56 AM, Adam Bishop <Adam.Bishop@jisc.ac.uk> wrote:
CentOS 7.2 is using OpenSSL 1.0.1e out of the box so *should* be unaffected...
Hopefully.
Is there a test for this issue (in the test suite or with eapol_test/radtest etc.) so I can make sure RedHat haven't helpfully backported the bug?
Jouni Malinin had a test, which involved GNU TLS on the client, and some esoteric TLS methods. i.e. the problem isn't *common*, but it's not exactly negligible, either. Alan DeKok.
On Mon, Dec 14, 2015 at 3:56 PM, Adam Bishop <Adam.Bishop@jisc.ac.uk> wrote:
CentOS 7.2 is using OpenSSL 1.0.1e out of the box so *should* be unaffected...
Is there a test for this issue (in the test suite or with eapol_test/radtest etc.) so I can make sure RedHat haven't helpfully backported the bug?
I triggered this by building the current snapshot of eapol_test against the GnuTLS version included in Ubuntu 14.04 (and confirmed that it also worked against unmodified GnuTLS 2.12.23 release built by myself). The behavior is same as in the earlier issues, i.e., the PMK/MSK from the authentication server does not match the PMK/MSK derived by the client when using EAP-PEAP (or EAP-TLS or TTLS). eapol_test prints this out in the end as an error. - Jouni
participants (4)
-
Adam Bishop -
Alan DeKok -
Arran Cudbard-Bell -
Jouni Malinen