SSL client profile, with client certificate auth, stopped working this week with Firefox 27.0 update

Workarounds!

it has to do with the new TSL 1.2 support in FireFox 27.0.

• in the client, about:config allows you to change security.tls.version.max to something less than the default "3"; of course, this deactivates TLS 1.2 negotiation with every other web, so it is NOT ok (and forces you to ask the user to change things)

   

• in the server, modifying the client SSL profile, adding (in advanced configuration) the "No TLSv1" option; that also is NOT OK, as SSL is insecure, old, blah blah... :)

   

is there any known bug with client certificate negotiation and TLS 1.2 support in F5 BIG-IP LTM?

hello, my workaround: running socat on local client and connect to big-ip-management-interface using my local ip with firefox 27.

example: big-ip (ltm 3600 10.2.4): ip=10.10.10.200/16 client: ip=10.10.255.254/16 url: https://10.10.255.254:8443/

(insert following line into /etc/rc.local, so it starts on reboot automatically)

socat -lf /var/log/logfile_loba.log -L /var/run/lobal.lock -d -d TCP-LISTEN:8443,fork,bind=10.10.255.254 TCP-CONNECT:10.10.10.200:443

now you can use "https://10.10.255.254:8443/" AND add an (permanent) exception to firefox' database. if you still using windows gg, try cygwin with socat.

hello, my workaround: running socat on local client and connect to big-ip-management-interface using my local ip with firefox 27.

example: big-ip (ltm 3600 10.2.4): ip=10.10.10.200/16 client: ip=10.10.255.254/16 url: https://10.10.255.254:8443/

(insert following line into /etc/rc.local, so it starts on reboot automatically)

socat -lf /var/log/logfile_loba.log -L /var/run/lobal.lock -d -d TCP-LISTEN:8443,fork,bind=10.10.255.254 TCP-CONNECT:10.10.10.200:443

now you can use "https://10.10.255.254:8443/" AND add an (permanent) exception to firefox' database. if you still using windows gg, try cygwin with socat.

Same problem here. On-Demand Certificate Authentication no longer works with latest Chrome or Firefox. With Chrome, problem started after updating to version 33.0.1750.117. I think the security fix CVE-2013-6659 is the root cause to this problem:

"The SSLClientSocketNSS::Core::OwnAuthCertHandler function in net/socket/ssl_client_socket_nss.cc in Google Chrome before 33.0.1750.117 does not prevent changes to server X.509 certificates during renegotiations, which allows remote SSL servers to trigger use of a new certificate chain, inconsistent with the user's expectations, by initiating a TLS renegotiation."

That's exactly what's happening here with the Virtual Server that has certificate from public CA and Trusted Root chain from private CA for Client Certificate Authentication.

At least it definitely has something to do with TLS1.2 because disabling it in the ClientSSL profile "fixes" the problem. Any help?

Hi,

I recently ran into a problem that had something to do with the SSL Handshake timeout value being changed from 60 seconds to 10 seconds, and a lot of browser-middleware couldn't handle that.

i.e. they open a connection, send the client hello, server replies with server hello and asks for cert, then the middleware kicks in to ask you the PIN etc, this "entering PIN procedure" probably takes more than 10 seconds, causing the F5 to reset the connection due to handshake timeout being 10 seconds.

Have you checked with a packet capture to see what is actually happening? Packets never lie! :)

Kind regards,

Thomas

Does anyone have an update on this or know of a known bug? We are running firefox 3.0 and 11.3 BIG IP LTM and having this issue.

We fixed the problem by upgrading to 11.5.0 at the time. Support gave me following explanation:

"This is Bug alias 451003 Client authentication with Chrome TLSv1.2, LTM SSL sent signature algorithms SHA1-RSA, SHA256-RSA, SHA384-RSA and SHA512-RSA in certificate request message but only SHA1-RSA is supported.

We advertise more signature algorithms than we are able to support, then chrome select an algoritm that we do not actually support, ad we end the ssl handshake. Chrome seems to select sha256 by default with tls1.2, if the server advertises it is capable of it.

This is fixed in 11.5.0 or later and the solution would be to upgrade BIGIP to 11.5.0 or later."

hello,

We had a similar case, however there is a parameter setting error in SSL Client Profile. Indeed, the certificate presented by the client belongs to an sub-authority and I checked only this one.

the problem is solved by adding a Certificate Bundle of the root authority and sub-authority.

Regards.