ACE SSL Proxy performance issue

Question

Hi I've got an ACE module in a 6500 that is being used as an SSL Proxy For a web service.
So the configuration is fairly basic, matches a VIP which has been Nat'ed from the public IP address port 443 and load balances over a number of reservers with the server ports being set to 80.
The problem is the main web site is hosted elsewhere and so when they switch to checkout on a secure port the browser page requests multiple https:// files .
The users are seeing very slow page loads a considerable amount longer than equivalent on http and more than you'd expect. The ACE is no where near any throughout or transaction limits.
My concern is on how the session is tracked, would the ACE attempt to renegotiate with every https:// get? I've seen example configs for stickiness inserting cookies for normal end-end load balancing but not with an SSL proxy configuration.
Sent from Cisco Technical Support iPad App

Answer 1

Hi Craig,
The SSL negotiation/handshake will happen everytime a client opens a new TCP connection i.e comes with a different source port.
To make sure that ACE doesn't renegotiate you can try and use this command:
(config-parammap-ssl)# session-cache timeout . You can use 24 hours or anytime you think is suitable.
This is basically to enable SSL session reuse. A little explanation below for your reference:
When client connects to a server over SSL, the server creates a session for that connection. This session ID is sent as a part of the Server Hello message. This is to make things efficient, in case the client has any plans of closing the current connection and reconnect in the near future. Most of the servers have a time out for these sessions (I think 24 hours is a common value, unless pressed for space).
When the client connects to the same server again, it can send the same session ID as a part of the Client Hello. The server will first look up if it can find any sessions with that ID. If found, the same session will be reused. Thus the time spent in verifying the certs and negotiating the keys is saved. If the server cannot find a matching session, then it responds with a new session ID and its certificate in Server Hello message. The client knows that it has to verity the cert and negotiate the key again.
Considerable amount of time is spent in validating server certs. Reusing SSL session will save this time.
Having said that you need to check if the client is coming with a session ID which it got in previous handshake or not. If it doesn't and it is a new TCP connection then SSL handshake will happen. Please enable that command before testing.
Also, ensure that you have allocated proper SSL resources to your context. Lack of resources can also cause dropped connections and sluggish performance.
Regards,
Kanwal