SSL decryption for offloading and visibility comparisons

Ted James
Ted James used Ask the Experts™
I need straightforward information on SSL Off-loading and Visibility.  Vendor documents and white papers lean too much to their product.  I have F5 10350v-f load balancers that have SSL and trying to decide between Local Traffic Manger (LTM) and SSL Orchestration which is more money.  My client is not sure what they want so I have to come up with something.  The 10350s sit in front of a DLP, with only two feeds coming to them so I don't think it should be complicated.  So the question with F5 10350 is which level of SSL decryption I should use.

On a separate program I am dealing with a Gigamon and Ixia packet brokers that will be routing to SSL decryption services as well.

Bottom line I just need objective definitions and comparisons when it come to SSL offloading vs ssl visibility vs ssl orchestration, etc. And in other SSL applications

Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Fractional CTO
Distinguished Expert 2018
You said "Vendor documents and white papers lean too much to their product" which got me laughing.

What's really required, today, is very different that what was required even a year ago,

It's questionable if any off this complex tech is even remotely required anymore.

At this point... If you're running the following, most of the performance issues disappear... meaning it's difficult to have a measurable difference between offloading, orchestration, native... where native means software like Apache + NGINX serve SSL certs themselves + handle all the entire SSL (really TLS) negotiation natively rather than any other cruft between users + Webserver. of a correctly configured site.

Entire SSL negotiation time == 75ms. If you run through any type of hardware, the lag between the hardware doing SSL along with proxying packets back + forth... most likely any hardware will only make speeds like this slower.

SSL config items to have working for lightning fast SSL.

1) Run HTTP/2

2) HSTS on.

3) OCSP stapling on.

4) Session resumption (caching + tickets) on.

Setup your SSL config like this with a native server first... meaning Apache listening on a public IP with no hardware between.

Get your SSL negotiation time <100ms, then start adding in expensive tech hocked by companies + retest your site speed.

My guess... you'll be getting rid of a lot of expensive hardware.
David FavorFractional CTO
Distinguished Expert 2018
One other passing point to keep in mind, as some vendors selling gear + services recommend this.

At all cost avoid any Public Key Pinning in your SSL config.

Anytime you read any vendor docs suggesting this, do a 180 + run, fast as you can.

If you Pin your site to a vendor's IP + with HSTS enabled, let's say for 2 years.

This means anyone who visits your site, can only visit your site for the next 2 years, if your site is still running on your vendor provided IP.

So... this is a great way to sucker people into having to stick with some vendor forever, because returning visitors will never see your site again, if the IP changes.

I won't mention any vendor's names.

Suggestion: Always keep 100% control of your SSL config. Never hand this over to any vendor. Ever. Period.


Thank you David

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial