Cracking the Code of SSL and TLS – Part 2
Part 2 – How SSL acceleration provides performance without compromise
Continuing on from part 1, where we learned many of the terms used and how a secure conversation is established, here’s a question…
What happens when we decide we need some acceleration for the applications we’re accessing via HTTPS? Well, as I have mentioned in the past if you’re using Riverbed SteelHeads to provide that acceleration, they can operate as a trusted man in the middle. You just need to give them the tools to do the job and they’ll get on with it.
Those “tools” include the following:
- A particular type certificate that matches the certificate of the application server that we want the SteelHead to accelerate. This certificate is called a “proxy certificate” and it will have been signed by a Certificate Authority, CA, that is recognised and trusted by the client device (PC, laptop, tablet, etc.) that is accessing the application. Quite often we’re really meaning the web browser running on the client device rather than the device itself.
- A suitable release of software that supports the TLS version and ciphers used by your client and server.
It’s not much to ask for is it? But without these tools, the SteelHead is simply not able to crack the code which means there is no ability to provide the full suite of optimisation techniques including data reduction and application acceleration.
The good news is that SteelHeads have been operating as a trusted man in the middle, using these tools in customer’s production networks for more than twelve years. Not only that, but those production networks are operating in many of the most security-sensitive enterprises and organizations in the world, for example, Government and Defense, financial services, manufacturing, healthcare, and others. So I’d like to think that SteelHeads are well proven. I would also like to say that the way they achieve this is very clever and perhaps unique in some aspects. But the reality is that it’s very similar to the way that other network devices like load balancers, smart firewalls and some web proxy devices operate. In other words, the SSL/TLS techniques inherent to SteelHead are generally well recognised in the world of IT security.
Yes, establishment of trusts and the strength of ciphers has evolved over those years. But the SteelHead software has evolved to keep pace. Not only that, but SteelHeads are accredited with Common Criteria and FIPS certification to operate in some of the world’s most secret of secret environments. So even though you might not be in that line of business, you can be sure your SteelHeads have been proven to those exacting standards.
Here’s the thing. Although the topic of secure communication and the acceleration of applications that use TLS to set up the encrypted session between client and server might seem complex, it’s like most other things in the world, once you have a grasp of the terminology and what is required, it’s fairly straightforward.
For SteelHeads it might seem confusing at first. Why? Because there are two SteelHeads. One at the client side of the WAN and one at the server side. What do you configure, and where? In fact, it’s quite easy! Once you realise that it is the SteelHead on the server side who handles the trusted man in the middle activity, it’s clear that that is where all the setup is done. Which kinda makes sense because the server side is the data centre, and that’s where all the “security stuff” should be done. The last place you should be setting up secret things is at the branch where it’s unlikely that security is quite as rigorous.
The set up is simple and can be broken down into a handful of tasks:
- Because the most common approach is to use proxy certificates, make a list of all the application servers that you want the SteelHeads to accelerate TLS encrypted applications for.
- For each server on the list, generate a Certificate Signing Request (CSR).
Hint: If there are lots of servers, some organisations create a single CSR that specifies some, or all, of the server names to be included as part of the same certificate. It’s called a Subject Alternate Name or “SAN” certificate.
- Deliver the CSR to a CA who can create the proxy certificates.
Hint: Most large organisations have their own CA which makes this even easier.
- Install the proxy certificate(s) on the SteelHead that lives at the server side.
- Tell both the client-side and server-side SteelHeads that they can trust each other to accelerate the encrypted traffic.
That’s really all there is to it.
As long as the client devices have their certificate stores populated with the CA that signed the proxy certificate(s) used by the server-side SteelHead, everyone can trust each other. The SteelHeads can get on with their job and accelerate encrypted traffic without compromising the secure communication from end to end.
OK, there are a few other things to consider. There are different cipher suites, certificates that are linked to other certificates (they’re called, certificate chains), client authentication, encryption of data at rest, and perhaps a few other items. But the SteelHead can handle these, in most cases it’s as easy as checking a box. In other words, a lot of the complexity is taken care of by the SteelHead behind the scenes.
Simple, secure, trusted.