ACE cookie-insert stickyness

[sandevsingh]

Hi, I am trying to understand the ACE`s cookie-insert method of stickiness. So the ACE will always insert a cookie into the http-header when sending a response to the client/browser. Based on that if it recieves the same cookie-id in the subsequent requests it knows to which end-server to send it as it does an internal hash based on the cookie-value.

My question is, what happens if the server also sends a cookie? Does ACE dis-regards that cookie and inserts a new one on it`s own? How do the cookie-insertion from the server (which is done by default by the web-servers) co-exist with the cookie insertion by the ACE?

thnx

[rhgtyink]

Hi,

As long as they don't both use the Same Cookie name they won't influence each other.

If you don't assign a cookie-name ACE will create a unique one per rserver.

Or you can configure one e.g.

rserver WebServer1 80

    cookie-string "ACEWS1Cookie"

More details can be found here:

http://www.cisco.com/en/US/customer/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/sticky.html

[sandevsingh]

Thanks for the reply, we got a security scan done of our public VIPS that were served by the ACE and had to remediate the cookie flag to be "Secure" and "httponly". Initially, I planned to do this from the ACE as it was doing a cookie-insert, BUT I asked the developer if he could do it from the server side. To my surprise, the fix from the server worked and we do we see the cookie now with the right flags in the scans from outside.

So does this mean, the ACE respects the cookie flag markings that it gets from the server?

[rhgtyink]

The ACE will only manipulate the Cookie that is used in the Sticky configuration, all other cookies are untouched.

In that case this Security scan is not valid, cause you can't gain anything from stealing the sticky cookie from a user.

That security check is valid for session cookies which can be used to steal/hijack a users session.