Whether you are a developer or a power user, security tends to pretty close to top-of-mind when developing/using applications. A common situation in either case is needing to use, integrate, or otherwise connect with an unsecured, remote application.
Case Study/True Story
Several years ago, I ran into such a situation at work.
In developing a rudimentary, very custom, proprietary CDN, I had to develop a basic web/application server whose sole purpose was to communicate via TCP with remote endpoints, transferring necessary information.
So, being a couple years out of school, I rushed headlong into implementing such a server using my favorite, high-performing language, C. Being under the gun to get this project done, I quickly completed a working product and was super chuffed with myself with how well it worked.
Then I remembered the security requirement.
"Ok, no problem," I said to myself, figuring the classic idiom, "How hard could this possibly be?"
After a day or two spent doing said research, the answer to the above question dawned on me. I stopped everything I was doing and blinked.
I blinked again.
I pushed my chair back from my desk.
I stood up, left the office late at night, and headed straight for the nearest bar.
I did not pass Go.
I did not collect $200.
The amount of proper effort required to implement the necessary security in my fledgling server was mind-boggling (at least at the time). I had no desire to gut my code, let alone the time to do it. I mean, it already worked brilliantly, except for this one important part.
So, what was the answer? Ignore the security requirement? Uproot existing infrastructure and spend time and money finding and deploying a more secure solution? Rewrite a bunch of code?
The answer, unsurprisingly, was a resounding "HECK NO!"
The next day I went back to work, albeit a tad hungover. I took a new tack in tackling this challenge. In my research, I came across an open source project which, honestly, saved my bacon. It was a project that effectively turned unsecured connections into secured ones. Brilliant!
Its name: Stunnel.
With Stunnel, I could route any traffic over any port and have a secure tunnel to do it in, without needing to change any code. Awesome! The overhead was low, and the configuration was dirt simple. The only additional item I needed was the appropriate certificate. My proverbial bacon had been saved!
This works on every single level. Also, bacon.
Stunnel prides itself on being portable and scalable, being OpenSSL-based. Whether its a Windows platform or a *nix one, it will run. Large deployments are also typically quite easy to accomplish.
The project founder remains very active in development and support, especially via Stunnel's mailing list, with releases made regularly.
Now let's see how we might configure Stunnel!
After installing the application, what do some example configurations look like? Let's take a look at some examples provided on the Stunnel site itself.
Let's say we want to secure a web connection but the web server does not have SSL/TLS engaged:
;[https] accept = 443 connect = 80 cert = /usr/local/etc/stunnel/stunnel.pem
We simply point Stunnel at the cert, tell it which external port to listen on (the "accept" line), and tell it which port to route the accepted connection to (the "connect" line).
Here is an example showing how you might secure a pre-existing MySQL deployment:
; Non-standard MySQL-over-TLS encapsulation connecting the Unix socket [mysql] cert = /usr/local/etc/stunnel/stunnel.pem accept = 3307 connect = /run/mysqld/mysqld.sock
The only difference here is that we point the "connect" line at the MySQL daemon's socket file.
Numerous other options are available to meet your security and technical needs, but are outside the scope of this introductory post.
What are some other potential uses for Stunnel?
SMTP/POP3/IMAP servers that weren't setup to accept TLS.
Web servers that weren't setup to accept SSL/TLS.
Database servers that weren't setup to accept secure connections.
Securing an application that was never designed or implemented to accept secure connections.
Securing an application that has no way to have secure communications implemented.
...the list goes on!
This post presented a possible solution in some cases where securing an application or channel is not necessarily easily accomplished through traditional means. By making using of Stunnel, we are able to keep existing systems in place with only a minimum of work necessary to secure the unsecured.
Stunnel remains in active development and is a mature technology, having been around for at least the better part of a decade. I encourage you to have a look!
Thanks for reading and we'll see you on the next post!