If I may add a few thoughts:
-
Depending on the client agent, SSL persistence may or may not suffice. Modern browsers will indiscriminately force SSL renegotiation, for good reason, but it will break SSL persistence. If you do end up using it, you should consider source address as a fallback. Still not 100%, but better than nothing.
-
As all have said, if you don't at least terminate the SSL on the client side, then you cannot see the clear text HTTP traffic. Consider that a) you can re-encrypt to the server for a logical end-to-end SSL path, b) the decrypted layer 7 payload exists only within memory space in the proxy if you decrypt and re-encrypt, and then only within the threads of a single TCP session, and c) you'd be offloading SSL onto a default deny appliance, with the ability enforce cipher strengths, handshake and bulk crypto requirements, and even mutual SSL authentication, all before a single packet reaches your servers. Further, without the ability to see the application protocol payload, you lose most of the functionality and flexibility of this high performance proxy. You could, for example, insert a web application firewall, an authentication gateway, and a web acceleration engine. You could also optionally spin a copy of this data off to an IDS/IPS and enable additional malware defenses. All of these things would otherwise have to happen within the application framework itself.