03-26-2013 06:07 AM
Hi All,
A security audit discovered one of our application's SSL termination, resides our ACE, supports SSL Renegotiation, which is, in their opinion, a security risk. As far I know, it is not supported to turn off this feature on ACE. Anyway, I want to be sure, before I reports this to the auditors. If you know, how to disable it, please share with me!
We are running 3.0(0)A4(2.2).
Regards,
Tamas
03-26-2013 07:01 AM
Tamas,
Here you have the link and below the configuration guide details:
The SSL session rehandshake enables the ACE to send the SSL HelloRequest message to a client to restart SSL handshake negotiation. The rehandshake is useful when you want to ensure security by reestablishing the SSL session.
By default, SSL rehandshake is disabled. To enable the SSL session rehandshake function during a session, use the rehandshake enable command in the parameter map SSL configuration mode.
The syntax of this command is:
rehandshake enable
For example, to enable the SSL rehandshake function, enter:
host1/Admin(config)# parameter-map type ssl PARAMMAP_SSL
host1/Admin(config-parammap-ssl)# rehandshake enable
To disable the rehandshake function, enter:
host1/Admin(config-parammap-ssl)# no rehandshake enableBy default, SSL rehandshake is disabled
PD: If this answers your question, mark it then other users can have it as reference.
Hope this helps!
Jorge
04-15-2013 06:16 AM
Hi,
I am in the same situation.
Someone has done a security vulnerability scan and claims that a VIP in the ACE is vulnerable to "SSL/TLS Renegotiation DoS".
I have confirmed that rehandshake isn't enabled either globally in the context or in a ssl parameter-map.
Then I did a test myself using openssl and the rehandshake was successful.
openssl s_client -connect
(Type "R" and enter on a line)
I even had a look at it with wireshark to confirm that the renegotiation really took place, and it did.
Also if I type the ACE command "sh stats crypto server term" I can see the counter "TLSv1 secured rehandshakes" increasing when I did the test with openssl.
A bit more of reading tells me the following about the rehandshake parameter in the ACE:
"Enables rehandshake, allowing the ACE to send an SSL HelloRequest message to its peer to restart SSL handshake negotiation"
This is telling me that the ACE doesn't send an SSL HelloRequest if the command isn't configured.
But it doesn't say if the client may send a ClientHello.
The testing I did indicates that the client may do a renegotiation after all.
So the question remains. Is there a way to disable renegotiation (even from the client side)?
Best Regards,
/Torbjörn
04-15-2013 05:57 PM
tvirtanen,
Depending on your version you might have it enabled or disabled by default, what version do you have it? and I can let you know if you got enabled or not
Jorge
04-16-2013 12:27 AM
Thank you for your answer.
Our running version is A5(2.0). It should have rehandshake disabled by default.
Here are the outputs from some commands:
ACE# sh run | i rehand
Generating configuration....
ACE# sh parameter-map SSL_TERMINATION
Parameter-map : SSL_TERMINATION
Description : -
Type : ssl
version : all
close-protocol : none
expired-crl : allow
cdp-errors : reject
authentication-failure any : reject
session-cache timeout : disabled
queue-delay timeout : disabled
Accepted cipher list:
RSA_WITH_RC4_128_MD5 (priority:1)
RSA_WITH_RC4_128_SHA (priority:1)
RSA_WITH_AES_128_CBC_SHA (priority:10)
RSA_WITH_AES_256_CBC_SHA (priority:1)
rehandshake : disabled
purpose-check : enabled
As you can see there is no configuration command to activate rehandshake.
So my question is if the rehandshake command only affects the ACE´s ability to do a rehandshake from its own side, but always lets the client do it if it wants to.
It isn't easy to find details about this. And the only place where I have found i little bit of details says "Enables rehandshake, allowing the ACE to send an SSL HelloRequest message to its peer to restart SSL handshake negotiation", so it might just be in that direction.
A followup question would be if it is possible to prevent the client from doing a rehandshake by a command in the ACE.
If this behaviour is not the intention this has to be a bug and I would go to the TAC with it.
I just want to know how the ACE is intended to work before I do that.
Best Regards,
/Torbjörn
04-16-2013 05:52 AM
Tvirtanen,
By default, SSL session rehandshake is disabled for A5.x
You can enable it if you want:
Jorge
04-16-2013 05:59 AM
Hi Jorge,
Yes, I know that it is disabled in this version. And I want it disabled.
But my test earlier in this thread shows that clients still can do a rehandshake.
You haven't mentioned that part.
Is this command just there to enable/disable the ACE itself to initiate the handshake?
It doesn't seem to have any effect on client initiated rehandshake.
BR,
/Torbjörn
04-15-2013 10:02 PM
This the same, I answered for Jorge too vie e-mail, but it doesn't included in the thread. Sorry for that!
My running version is already posted in the first post. Please let me know, if there is any version to disable SSL rehandshake by clients!
04-16-2013 05:53 AM
Tamas,
By default, SSL session rehandshake is disabled for A4.x and A5.X
Jorge
05-10-2013 03:32 AM
Hi,
I understand that this is disalbled by default, but it does stil works, when client starts the renegotiation, as Torbjörn explained detailed. So the question remains the same. How could I avoid to accept client initiated renegotiation?
Regards,
Tamas
05-11-2013 02:21 AM
Hi,
If you are using SSL offloading on ACE then it does not make sense. Please raise a TAC case to investigate further.
If SSL negotiation is happening between server and client ( ACE acting as just L4 ) then server is the one who can control this parameter.
regards,
Ajay Kumar
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide