In our solution, we also use Indy-based transport channels and we’re increasingly encountering requests for SSL-encrypted communication using the latest versions of the OpenSSL libraries (libcrypto-x/libssl-x). As is well known, Indy only supports older versions of the OpenSSL libraries (libeay/ssleay); fortunately, third-party solutions have emerged that allow Indy to run with the latest versions of the OpenSSL library—specifically, TaurusTLS.
Server-side replacement is straightforward—SSL handler is created and connected to IndyServer component in the code manually, so it’s no problem to use Taurus SSL handler instead of Indy SSL handler.
On the client side, it’s a bit more problematic. Indy-based client channel classes have use of Indy SSL handler “hard-coded” via private variable `fSSLHandler`, into which an instance of the Indy SSL handler is always created, and it’s not entirely easy to swap it out for Taurus SSL handler.
I created derived classes where I replace the SSL handler in the `BeforeDispatch` method, and it works quite well. It’s a workaround and not very elegant.
Please consider modifying the architecture of client transports to allow the use of an alternative SSL handler; many developers who use Indy and face a similar problem would appreciate it.
That’s the principle behind my patch, of course. But it’s not exactly a neat and clean solution, because the private variable fSSLHandler is created unnecessarily, even though it isn’t used for anything..
I understand - automatically activating Indy’s internal SSL handler for SSL-aware protocols (https, tcps, supertcps, superhttps) is a smart solution. Unfortunately, it reaches its limits when Indy’s native SSL solution no longer meets current requirements and needs to be replaced with a third-party solution… which is quite easy, thanks to Indy’s modularity.
Perhaps, client transport classes could be extended with a new event, something like `OnCreateSSLHandler`, which could be used to inject a non-native Indy SSL handler into a channel instance. If the event were not set, or if it did not return a handler instance, the native Indy SSL handler would be used, just as it is today.
I’ve added a new define. it’s defined by default, i.e. current behavior isn’t changed.
it can be disabled in RemObjects_user.inc if current SSL support for Indy channels isn’t needed.