Been working with TLS DHECE certificate based handshake with a FreeRADIUS server and WPA_supplicant - both running OpenSSL 1.0.1j FIPS.

Afer watching the Wireshark traffic, I notice that the client sends a Client Hello using TLS 1.0. I beleive that the ECC certificates have an issue with OpenSSL / TLS 1.0.

I have tested s_client and s_server with the same certificates using TLS 1.2 and it was SUCCESSFUL.

I cannot seem to figure out how to change the TLS version from 1.0 -> TLS 1.2 on the client hello message. Perhaps, because TLS 1.0 doesn't support ECC ciphers there could be an issue? However, it SHOULD force a TLS 1.2 because the new version of SSL supports it and the ciphers.

In addition, the handshake fails with a "SSLv3_GET_CLIENT_HELLO Fatal HandShake Error" during the first step of the TLS 1.0 handshake.

Any thoughts on the matter?

  • It's not clear exactly what you are saying. Although OpenSSL (annoyingly) uses different spellings in some places like AECDH instead of ECDH_anon, neither OpenSSL nor any standard uses DHECE. I'm going to guess you meant key-exchange ECDHE_? (ephemeral) and not ECDH_? (fixed aka static). You also mention "ECC certificate"; I'll assume that means a cert for an ECC key, although other meanings are possible, and therefore ECDHE_ECDSA rather than ECDHE_RSA. If that's not what you mean, please edit. ... – dave_thompson_085 Oct 31 '14 at 7:37
  • ... In any case, there is no "issue" with ECC certs, or ciphers, in TLS 1.0. rfc4492 (ECC) was written about the same time as rfc4346 (TLS1.1) and some implementations implemented them together, but OpenSSL did ECC in 2006, on TLS1.0 and even nonstandardly on SSL3, but TLS1.1 and 1.2 only in 2012. RedHat packages of OpenSSL did until recently exclude all ECC (for all protocols) but assuming your s_client/s_server test uses the same package it must be okay. ... – dave_thompson_085 Oct 31 '14 at 7:38
  • ... You identify your OpenSSL build as FIPS-capable, and there are two variants of the FIPS module (2.0) for OpenSSL 1.0.1, one with only partial ECC support; if your programs set FIPS mode, which commandline s_client/s_server don't by default, that might cause a problem. Anyway: do you have any handshake or alert message after the ClientHello, and if so what? If you have any (related) log messages on the server, post them. OpenSSL 1.0.1 supports TLS1.2 depending on what methods and options the apps use, and that may be a separate issue, but it is not related to ECC. – dave_thompson_085 Oct 31 '14 at 7:47
  • dave_thompson_085, thanks for the feedback! After doing more research, it seems to be that ECHDE-ECDSA is supported, however, it requires TLS 1.2. Since both the client and server are running up to date openssl (not FIPS, my mistake, j), I am assuming that the handshake is failing right away because the ECDHE requires TLS 1.2 and wpa_Supplicant/ openssl is starting the client hello with TLS 1.0. I've been trying to track down in the openssl source code (a jungle) a way to force a TLS1.2 connection. Do you have any suggestions on how to force TLS1.2? I know that it works w/ s_client. Thx – userJoe Nov 1 '14 at 1:04

At most a partial answer but too much for reasonable comments.

ECDHE does NOT require TLS1.2, only 1.0 as I said in the comment. I used it often in openssl 1.0.0 which doesn't even implement 1.2, and still test fine by specifying 1.0 in current openssl or using non-bleeding java (j7 can do 1.1 and 1.2 but defaults to 1.0). In fact openssl actually supports ECDHE (and other ECC features) on SSL3, which the RFC does not call for so it works for openssl-to-openssl but not necessarily with other implementations; but there is no good reason to use that when more robust TLS1.0 is available. The only cipher features that require TLS1.2 are AEAD (in openssl GCM) and SHA2. If your app(s) is requiring say ECDHE-ECDSA-AES128-SHA256 but not ECDHE-ECDSA-AES128-SHA, that would fail on 1.0. What ciphers are offered in your ClientHello? Some googling finds http://w1.fi/wpa_supplicant/devel/tls__openssl_8c.html which suggests at least the possibility to specify the list of ciphers as of 2012, but I didn't see any doc on if and how a user controls this.

Which reminds me: are you looking at the correct version in ClientHello? There are two versions: record layer and handshake. OpenSSL uses "Record Layer" version 0301 (TLS1.0) for ClientHello to offer a range of protocols, to ensure a peer that implements only an older version will "negotiate down" correctly; it is the version under "Handshake Protocol: Client Hello" that specifies the offered version. And you still didn't say what the response is in Wireshark: is there an alert and with what code, or something else, or what?

That said, you may want TLS1.2 for its other benefits or just futureproofing. Among the protocols that openssl implements, the ones it offers for a client or accepts for a server are controlled by calls the respective client or server application code makes. The starting point for an SSL_CTX are "methods" for a specific protocol like SSLv3_*method or TLSv1_2_*method, or the "generic" SSLv23_*method (a legacy name that is now misleading and may be changed in a future openssl version) followed by SSL_[CTX_]set_options with (among others) SSL_OP_NO_(protocol) bits.

Assuming per above your ClientHello is record version 0301 AND handshake version 0301, meaning TLS1.0 only, it might well be that wpa_supplicant was coded to do specifically TLSv1_*method. This could have made sense ten years ago when TLS1(.0) was the best available, and there were issues with SSLv2 being attackable and SSLv3 being unacceptable for USgovt use (though then actually safe) so someone might reasonably have felt "we'll protect those @#? users from making a mistake and doing something insecure by forcing TLS1". If so, the passage of time has made this thinking wrong.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.