cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
15930
Views
0
Helpful
10
Replies

How to disable SSL Renegotiation

Tamas Eperjesi
Level 1
Level 1

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

10 Replies 10

Jorge Bejarano
Level 4
Level 4

Tamas,

Here you have the link and below the configuration guide details:

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA4_1_0/configuration/ssl/guide/initiate.html

Enabling SSL Session Rehandshake

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 enable

By 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

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 :443
  (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

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

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

Tvirtanen,

By default, SSL session rehandshake is disabled for A5.x

You can enable it if you want:

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA5_1_0/configuration/ssl/guide/terminat.html#wp1220088

Jorge

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

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!

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

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

Review Cisco Networking for a $25 gift card