Hi, catching up after being out of office when "Poodle" arrived. I'm wondering if FreeRADIUS is strictly enforcing TLS 1.0+ when negotiating a PEAP/TTLS tunnel. And if not, how to make it so :-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Stefan Winter wrote:
catching up after being out of office when "Poodle" arrived.
I'm wondering if FreeRADIUS is strictly enforcing TLS 1.0+ when negotiating a PEAP/TTLS tunnel. And if not, how to make it so :-)
From src/main/tls.c: /* * Set ctx_options */ ctx_options |= SSL_OP_NO_SSLv2; ctx_options |= SSL_OP_NO_SSLv3; This goes back to at least 1.x. The poodle attack requires SSLv3. SSLv3 has been disabled for a very long time. Even if SSLv3 wasn't disabled, I think administrators would notice one user having 1000's of failed logins. Alan DeKok.
On 20/10/14 07:31, Stefan Winter wrote:
Hi,
catching up after being out of office when "Poodle" arrived.
I'm wondering if FreeRADIUS is strictly enforcing TLS 1.0+ when negotiating a PEAP/TTLS tunnel. And if not, how to make it so :-)
Alan has pointed out that SSLv3 is disabled, but in any event exploiting POODLE requires forcing the client to make variable content SSLv3 requests. It's tricky to see how that could be achieved with EAP clients. But SSLv3 is crap anyway so it's good it's disabled.
Incidentally, we now have TLS 1.2 in Windows for the relevant EAP-types after the last round of Windows Updates, currently disabled by default: https://support.microsoft.com/kb/2977292 I am not quite sure why they don't default to 0xFC0 though for TLS 1.0, 1.1 and 1.2 support. Are there really EAP-terminating RADIUS servers out there that baulk on a TLS 1.1 or 1.2 Client Hello, not responding with TLS 1.0 where the newer protocol versions are not supported?
On 20/10/14 14:24, Nick Lowe wrote:
Incidentally, we now have TLS 1.2 in Windows for the relevant EAP-types after the last round of Windows Updates, currently disabled by default:
https://support.microsoft.com/kb/2977292
I am not quite sure why they don't default to 0xFC0 though for TLS 1.0, 1.1 and 1.2 support.
Are there really EAP-terminating RADIUS servers out there that baulk on a TLS 1.1 or 1.2 Client Hello, not responding with TLS 1.0 where the newer protocol versions are not supported?
Almost certainly. There are some controller-based wireless systems which "helpfully" have the option of terminating the outer EAP, and only passing the inner EAP along to the RADIUS servers; I wouldn't ever do that, but I bet people who are would see all kinds of craziness. I'm sympathetic to Microsoft not wanting to open that can of worms..
For anybody interested, the configuration of the TlsVersions DWORD in the registry is more granular than the KB article lets on as you actually get control of both the client and server version behaviour, it is not lumped together. The values map to the SP_PROT flags defined in schannel.h, documented online as part of the SCHANNEL_CRED structure under grbitEnabledProtocols. http://msdn.microsoft.com/en-gb/library/windows/desktop/aa379810.aspx SP_PROT_TLS1_SERVER 0x00000040 SP_PROT_TLS1_CLIENT 0x00000080 SP_PROT_TLS1_1_SERVER 0x00000100 SP_PROT_TLS1_1_CLIENT 0x00000200 SP_PROT_TLS1_2_SERVER 0x00000400 SP_PROT_TLS1_2_CLIENT 0x00000800 For standards compliant TLS implementations, you just need an intersection of protocol support between client and server. I am definitely curious if anybody encounters a buggy SSL/TLS library in use in the wild that rejects a TLS 1.1 or 1.2 Client Hello... Nick
TlsVersion, not TlsVersions! On Mon, Oct 20, 2014 at 4:28 PM, Nick Lowe <nick.lowe@gmail.com> wrote:
For anybody interested, the configuration of the TlsVersions DWORD in the registry is more granular than the KB article lets on as you actually get control of both the client and server version behaviour, it is not lumped together.
The values map to the SP_PROT flags defined in schannel.h, documented online as part of the SCHANNEL_CRED structure under grbitEnabledProtocols.
http://msdn.microsoft.com/en-gb/library/windows/desktop/aa379810.aspx
SP_PROT_TLS1_SERVER 0x00000040
SP_PROT_TLS1_CLIENT 0x00000080
SP_PROT_TLS1_1_SERVER 0x00000100
SP_PROT_TLS1_1_CLIENT 0x00000200
SP_PROT_TLS1_2_SERVER 0x00000400
SP_PROT_TLS1_2_CLIENT 0x00000800
For standards compliant TLS implementations, you just need an intersection of protocol support between client and server.
I am definitely curious if anybody encounters a buggy SSL/TLS library in use in the wild that rejects a TLS 1.1 or 1.2 Client Hello...
Nick
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Nick Lowe -
Phil Mayers -
Stefan Winter