Advanced Threat Mitigations via SSL Intercept

SSL offload has been around for quite some time. But this technology was primarily developed for the web farm audience, offloading SSL traffic from the application servers and putting the load on application delivery controllers like F5’s BIG-IP. With the push for SSL Everywhere in the last few years, the need for corporations to have visibility to the traffic from their internal clients (could be employees or internal application services reaching out to external services via APIs) to external services that are encrypted. Without the ability to decrypt and inspect that traffic before it leaves the perimeter and as it returns from the outer reaches of the internet, corporations are exposed to significant risks such as information leakage and loss, general malware at best but botnet command and control communication channels at worst, but corporations are also exposed to the softer productivity risks like employee time management while on the clock.

This is where inspection via SSL intercept comes in. We partner with FireEye to offer combined best in class performance and visibility. Peter also sat down with Sam Ware from FireEye at RSA last year to discuss the solutions and partnership. But enough of the marketing…how does it work? In a traditional reverse proxy scenario, the SSL offload requires that you have the private key and certificate in order to decrypt and inspect. But with the forward proxy scenario, well, we don’t have the private keys to all the sites on the internet. So another solution is necessary. I’ve queued this episode of Whiteboard Wednesday at the point where the process of how to configure and insert the BIG-IP into the trust relationship between client and server is broken down.

Once the air gap is in place with the SSL intercept configuration, this unencrypted traffic can be diverted through inspection devices like FireEye to monitor and act on any disallowed or malicious traffic. There are a couple ways this can be deployed.

Layered SSL Intercept Solution

In this solution, there is a front-side and a back-side BIG-IP handling the encryption with clients and servers, respectively. In the middle, interesting traffic is unencrypted and passed through the inspect points. The great thing about this solution is the initial inspection point is on the BIG-IP, so if there are some destinations that require no inspection, those can be immediately re-encrypted and sent on without sending through the external inspection point.

One-Armed SSL Intercept Solution

In this solution, there is only one BIG-IP, and so the front-side and back-side functions of the air gap are combined into the single device. Functionally they are equivalent, just less hardware in the picture.

Clone Solution

In the event the enforcement angle of the solution is not desired, the traffic can be cloned off to the FireEye for monitoring and alerting, but still be passed along uninhibited by the infrastructure.

As simple as the drawings make it all look, the configuration is fairly complex. Thankfully there is a fantastic iApp supported by F5 to assist in the deployment. It is linked below in the resources.


Published Feb 23, 2016
Version 1.0

Was this article helpful?


  • the mechanics are simple, insert/replace of each valid Public-Key-Pinning header is supposed to clear out the old entries and set it to the values in the latest response. See section 2.3.1 of the RFC.


    that said, hpkp is complex and can brick a domain, so tread lightly and -report-only with much validation before pulling the trigger!


  • How well does this work for pinned (HPKP) certificates.

    Is it simply as straightforward as having the BIGIP remove or rewrite the

    header in
    , to one that is in line with the certs generated by your BIGIP?

    I presume that, if you are implementing this in an environment that has already received some

    , you are at the mercy of the existing
    of those values, unless you can also influence the resetting of browser state amongst your users?