When we started working with SSL VPN manufacturers to integrate our PowerTerm WebConnect with their products we quickly ran into a problem: PowerTerm WebConnect did not operate like other Server Based Computing / Remote Access products they had previously worked with. This meant that the integration method they had previously used was not applicable for PowerTerm WebConnect. Fortunately we succeeded in providing them with a solution that was both functional and easy to use. Consequently, PowerTerm WebConnect now integrates with a host of SSL VPNs including Juniper, Microsoft Whale, Array Networks, AEP, F5 and Check Point. In this post I will describe the problem we faced and the solution we came up with.
Before I can describe the problem we encountered I first need to briefly explain how SSL VPNs handle none-HTTP communication protocols, such as RDP. In order properly encrypt such communication protocols and enable them to pass through proxies and firewalls SSL VPNs encapsulate them within HTTPS.
Consider an application running on the client-side, C, that uses a none-HTTP protocol to communicate with a component on the server side, S. The SSL VPN redirects C’s communication to its own local component, often called a Port Forwarder, P. This component encapsulates the communication in HTTPS and transmits it to the server-side end-point of the SSL VPN, E, which extracts the original protocol from the HTTPS and sends it on to S in its original form (this is different than how SSL VPNs handle HTTP traffic because the browser natively supports HTTPS, and so a Port Forwarder is not required).
Redirecting the client’s communication from S to P can be accomplished by intercepting the low-level socket communication instructions. However, this method may require administrative privileges on the local device. An alternative method is to explicitly instruct the client to connect to an alternate (local) address. Two common Server Based Computing products use a configuration file that is downloaded to the client that is used provides the target address: Citrix uses .ica files and Windows Terminal Services uses .rdp files. Since these files are textual and have known formats, SSL VPNs can intercept them and modify them on route. The SSL VPNs extract the target address from such a file and replace it with local address belonging to the Port Forwarder. This also provides the SSL VPNs with S’s address so that the end-point knows where to forward the data it receives.
When we designed PowerTerm WebConnect we decided to forgo the use of downloadable, readable configuration files as a mechanism for providing clients with configuration information. This is because we view such files as a potential security risk, for example because malicious end-users can save and modify them. Instead we opted for a more secure mechanism by which the configuration information is downloaded directly from the server to the client via an encrypted communication channel and never saved to disk. This approach completely segregates end-users from configuration data. Unfortunately this also segregated the SSL VPNs as PowerTerm WebConnect’s communication channel was completely opaque to them as well – they could neither read it nor modify it. While this validated the benefit of our approach, it also prevented the SSL VPNs from using them same technique that they had used with Citrix and Windows Terminal Services for PowerTerm WebConnect.
Our solution to this was to provide a simple API, using a Web Service that enables SSL VPNs to query the PowerTerm WebConnect server for the information that it intends to send to a client. Specifically, the SSL VPNs can receive the address of the Terminal Server to which the client will be instructed to connect. We also enhanced the PowerTerm WebConnect client so that it could receive its target address via a command-line argument. When the client receives a target address via the command-line, that address overrides the address provided to it through the communication channel (for security reasons the address provided via the command-line was restricted to local addresses only). The resulting mechanism works as follows:
From that point on the mechanism works exactly as previously described.
This solution is both simple and straight-forward. We were able to implement it very quickly, thus enabling tight integration with existing and future SSL VPNs.