HTTP Header Reading with iRule?

If you don't terminate the SSL on the F5, you won't be able to see the HTTP header as it is still encrypted. You could try using an SSL persistance profile, but your luck may vary based on the browser and how long it will reuse an ssl session ID and so on.

If you don't terminate on the F5 your options are limited. I'm sure there are plenty of 'agents' that would like to look at those HTTP headers too, that's why you are using SSL/TLS right?

Assuming you are on a recent version of TMOS, why not try SSL persistence?

If I may add a few thoughts:

1. 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.

    

2. 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.

    

Thanks very much for the detailed answers guys.

By the sounds of it, we do really need to be terminating the SSL traffic, even if we re-encrypte it to the back-end servers.

Assuming we do this, where can we go and what's the best configuration? I have tried (and failed) with a simple HHTP profile alone.

Also, in terms of load (cpu, memory) etc.. does SSL termination put much strain on an F5?... We're looking at the lower spec ones initially.

Thanks,

J

Also, in terms of load (cpu, memory) etc.. does SSL termination put much strain on an F5?

there is some information here.

sol13067: Performance impact of transitioning to 2048-bit SSL keys

Typically, SSL termination doesn't put any load at all on the CPU:s, unless you're using VE or disable the native stack since the BIG-IP Appliances does SSL in hardware. To see the capability of each platform, check the data sheet,

http://www.f5.com/pdf/products/big-ip-platforms-datasheet.pdf

Assuming we do this, where can we go and what's the best configuration? I have tried (and failed) with a simple HHTP profile alone.

At a minimum you need client and server SSL profiles applied to the VIP. The client SSL profile should have, at a minimum, the server cert and key. If you're performing mutual SSL auth, then you'll also need to apply a trusted CA bundle for the system to be able to validate client certificates. In most cases you can use either the default "serverssl" or insecure default serverssl profile on the server side. The insecure profile just disables the secure renegotiation requirement between the proxy and the server.

Also, in terms of load (cpu, memory) etc.. does SSL termination put much strain on an F5?... We're looking at the lower spec ones initially.

Keep in mind that a BIG-IP (usually) processes SSL in hardware, so the SSL performance is always going to be higher than that of any commodity server. The platform data sheet lists SSL performance, both TPS (handshake) and bulk crypto numbers.

And back to the original question, once you terminate SSL, you very likely can skip the irule and use a persistence profile instead. If your goal is to simply keep people on the same server they originally landed on, the default cookie persistence profile should work pretty well.