Problem: You’ve got some 10-year-old code running on a 12-year-old platform that only supports TLS 1.0, and other “insecure” protocols that are deprecated or soon will be.
Solution: Reverse Proxy
Let’s not discuss how you got here (yet). But, you’re here. You’re running old code on an old platform that would require hundreds or thousands of staff effort hours to upgrade.
Your platform only speaks SSLv3 (already deprecated) and TLS 1.0 (mostly deprecated), and you just got a notification from your business partner that they are dropping all support for TLS 1.0 and 1.1, to coincide with MS Windows Vista’s End of Life date (4/11/2017), as many companies are already planning to do.
So what do you do?
Set up a reverse proxy.
It’s not as difficult as it sounds, and it will allow you some runway to resolve your “technical debt”, which is the fashionable term for “getting rid of your really old crap, and replacing it with something modern“.
Acting like a translator, a reverse proxy sits in the middle, accepting the older, incoming SSL / TLS connection from your “legacy” platform, and creating a new “modern” SSL / TLS connection to the real destination endpoint.
In the diagram above, we can see that an older application can’t make a connection to a modern endpoint. Using a reverse-proxy, the proxy allows an incoming connection using older protocols, and initiates an outbound connection using modern protocols.
2. The Insecure Protocols Landscape
In the last few years, we’ve seen the deprecation of:
- SSLv3 – once the defacto SSL standard
- MD5 – a once-legendary hashing algorithm, MD5 can be cracked in minutes, jeopardizing the authenticity of any signed packet or message
- SHA-1 – A perfect demonstration of what people with too much time and resources can do to disrupt the lives of the rest of us, Google has publicly-demonstrated that it can arbitrarily crack a SHA-1 hash (at a cost of $1M, I might add)
- RC4 – A venerable public-key cipher has been demonstrated to be weak under certain, specific conditions.
- 3DES – Although there is no known publicly-available crack for 3DES, it has been deprecated since 2007.
- TLS 1.0 – Like its cousing SSLv3, TLS 1.0 has publicly fallen due to a vulnerability that can be exploited under a specific, narrow set of conditions.
As time passes, our ciphers, hashes, key exchange mechanisms, and security protocols come under direct fire until they are smashed or broken.
Modern computer “security” depends on limited computing capabilities. Conversely, Moore’s law necessitates that all such security mechanisms will be breakable, due to the imminent increase in computing power over time.
So, in summary, anything that was 100% secure 10 years ago, is only about 25% secure today.
Welcome to the future.
3. The Case for Older Code
Every line of code is an investment. It takes time (and money) to write the code, check it, test it, and then qualify it. Then, it takes teams of people, weeks of time to promote your code in to production. And, there’s always the inherent risk that your code will completely blow up in production, causing an outage, downtime, loss of revenue, or reputational risk.
It’s easy to say, “hey, you should update your platform!”, but that might be a lot more complex and costly than it first appears.
3.1. Hopefully, You Implemented a Broker Tier
If you implemented a broker tier, you might be in good shape!
A broker tier allows you to support a variety of interfaces using small, replaceable code modules, called “brokers”.
If your platform includes a broker tier, you’re in luck! With a few hundred lines of code (minimal investment), you can write a new broker to support the modern protocols, without having to change your application’s main code modules.
Also, this is essentially a reverse proxy!
3.2. It Ain’t Broke, Don’t Touch It
The initial coding investment was made years ago. Other than support for new protocols and standards, this widget has been working flawlessly in production for years, and there’s no reason to touch it.
Often, coding a new widget (beyond the investment) results in reduced reliability, and unpredictable behavior. Even if you hire developers to “clean code” to the original specification, sometimes it takes YEARS to find all the flaws and simply get back to the point where you started with the OLD code.
3.3. Just Port Your Code
Anyone who has “ported” code knows that it’s not that easy. Everything from data type differences to library function variations are waiting in the wings to make your code-porting-project costly and unreliable.
3.4. Just Update Your Middleware
In theory, managed code can simply run on updated middleware. You might not even have to recompile.
In practice, however, upgrading your middleware platform can be a nightmare. Between major releases, there are often major structural changes that result in “the old way” being deprecated in favor of “the new way”. So, before you know it, you’re in the middle of a code-porting project, more than a middleware upgrade project.
In addition, each major version of your favorite middleware has its own “characteristics” that may result in unpredictable behavior or lack of reliability.
3.5. Switch to Cloud / COTS
Maybe there is a Cloud widget, or maybe there is a “Commercial, Off-The-Shelf” widget that does exactly what you’re doing today.
The customization paradox: You need customization to support your business. Customization needs to be completely re-implemented between major platform versions, and thus customization COSTS your business.
Rapid evolution is the hallmark of “the cloud”. Unfortunately, this means that any commercial, third-party library (cloud or COTS) is going to require constant maintenance, in order to keep your platform current.
4. Let’s Talk About Reverse-Proxy
As mentioned above, a reverse-proxy allows your OLD CODE to talk to NEW PLATFORMS, by sitting in the middle.
4.1. F5 / Application Delivery
Also known as a “load balancer”, application delivery allows you to follow specific rules for specific client connections.
If you’re lucky enough to use F5 Networks Application Delivery Controllers (ADC), then you have the answer at your fingertips.
F5 has the unique capability to establish a “front-end” and “back-end” SSL session, and the F5 can perform pattern matching or re-writing on anything between the two.
By simply configuring a “modern” SSL profile, you allow the F5 to use modern protocols and ciphers to connect to any endpoint you wish.
Then, configure a VIP on your local network, whose pool is a single node consisting of the “real” destination endpoint.
The final step is to configure your application to point to the VIP rather than the real endpoint, and no one will know the difference.
When the application platform opens a connection to the ADC’s VIP, it allows the use of older protocols. The ADC then manages the outbound connection to the “real” endpoint, using the modern SSL profile, supporting modern ciphers and protocols.
4.2. Proxy Module
Like a broker tier, writing a proxy module is the second-easiest option!
Install a “modern” managed code instance (perhaps *gasp* on MODERN hardware), and write a tiny proxy module that accepts an inbound connection, while forwarding the data to a new, configurable outbound connection.
The managed code platform “handles” the nuances of modern protocols and ciphers automatically.
4.3. Configure a Transparent Web Proxy
Using Squid, or a similar proxy, you can set up a simple VM (Virtual Machine), acting as a squid server, that allows the application to make outbound calls, while Squid breaks the request apart, and makes its own connection to the endpoint.
Best case, if your platform is proxy-aware, it can simply point to the Squid VM.
If not, squid can be configured as a “transparent proxy”, so that the platform and application don’t even know that Squid is involved.
Squid can then be configured to make its own connection to the real endpoint.
Reverse-proxy is a cheap and easy way to preserve the original code investment and reliability of long-lived code modules that happen to be running on deprecated platforms.
This approach won’t last forever, but it buys a few years to develop and debug a new strategy.