SSL over TCP/IP

This is my first post in blogspot, this is not my first post ever, I do have a personal blog written in hebrew in which I'm anonymous, I decided to open this blog to talk about my technical experiences, something I can't do in my personal blog.

So without further adieu lets go into the technical nitty gritty :)

Currently I'm working on a project that needs to take unsecure traffic on one end, and send this data using SSL to another secure location, the interception is done using LSP and I've decided to use my redirector product (http://www.komodia.com/index.php?page=redirector.html) as a base platform. Currently the redirector doesn't support SSL and takes and outputs normal traffic, if the traffic is encrypted it can only redirect it as is, changes will be noted by initiating or ending party.

So....I thought, lets change the redirector to output SSL on one end, and since I'm an avid user of C++ design patterns and didn't wish to rewrite the "redirector" or refactor the entire code base I've decided to create a socket class based on my TCP/IP library (http://www.komodia.com/index.php?page=newtools.html) CTCPSocketAsync. Naturally I thought of OpenSSL as the library to use, I researched if it's possible to use asynchronous sockets and OpenSSL and I came across this nice project (http://www.lenholgate.com/archives/000456.html) that included a source code of SSL using asynchronous sockets based on MFC framework (something I try to avoid, which made me start writing the TCP/IP library back in the days), but it gave me a good start to learn and understand how OpenSSL operates.

I started with compiling the OpenSSL, it wasn't hard, I still remember the time it took me to compile Mozila/NSS platform, arghhh, I used this nice guide to help me (http://www.devside.net/guides/windows/openssl), then I assembled OpenSSL code on top of a new class called CTCPSocketAsyncSSL (how original), at first some concepts in the sample I learned from weren't clear, however after debugging my code I understood what and why. I took a different approach then the sample, I like to keep infrastructure operations and I count SSL handshake as such, under the hood, if the user wants to do something with that, I allow it, but for most users they don't really care, all they want it Send/Receive and that's it.

After two nights and 1500 lines of code, I got the class to work as SSL client, and I will finish the class tomorrow to be a SSL server as well. After I got the class working I was excited because I'm planning to release version 5.1 of the library and as far as I know there aren't good open source asynchronous socket soluttions (I don't like GPL because it hinders you, you can't use it in commercial applications!) and of course other solutions cost money. V5.1 is going to change this, I think I will release it in one or two weeks, still got to finish some other work before I can dedicate the time needed to release the new version.

So now what? I will incorporate the SSL code into the redirector and then I'll see which SSL solution I will deploy on a Linux machine, would it be perl script or Squid proxy server?

Until next time,
Barak