Compatibility

Web applications may be more or less compatible with HttpVPN. To explain what makes an application more compatible, one needs to know what exactly HttpVPN does. In the nutshell, when HttpVPN Proxy sends HTML pages created by your app to the Portal, local URLs on those pages get replaced with Portal-based links/URLs. For example, a link pointing to http://machinename:12345/page.html will be replaced with something looking like https://MyOwnSecureWeb.com/6F7ACF0F-F780-4495-B955-99EEDD8CC4D9/SecureTunnel.axd. HttpVPN does this URL replacement very well in vast majority of cases, but in some situations finding links is harder than in others. This means that regular href, src and other references in HTML are easily found and replaced very quickly and efficiently. However if a URL is assembled in the client-side script at run time from small pieces, HttpVPN Proxy won’t be able to replace such URL. Still, there is a Portal-side last-chance fixer for such resources – an intelligent 404 handler that attempts to figure out whether given missing resource was meant to be retrieved from the LAN application, and to forensically restore the original URL. These two stages manage to correctly replace 98%+ of all links. To give you an example, residential internet routers, like Linksys, have web-based management page. It is usually fully compatible with HttpVPN. On the other hand, JavaScript-heavy MS Ajax control toolkit has about 80% of controls working fine, and others not so well. We are continually improving our URL finding logic to make most web applications compatible with HttpVPN without developers having to do anything at all.

The bottom line is: in order to keep your applications compatible with HttpVPN, avoid putting URLs together in the client-side scripts.

Performance

In the beginning your application will likely to be slower than it would be if it was just hosted on Internet. The reason for that are two extra intermediaries between your application and your browser: the HttpVPN Proxy and the Portal. However, due to Portal-side caching and compression, serving HTML, XML and other files may actually work faster than it would be with regular hosting. Compressed content, like media files, will be delivered slower in pretty much all cases. Therefore cache-management settings/headers set by the application will go a long way to improve the performance. Performance of the entire HttpVPN system will keep improving over time. There are lots of exciting performance tweaks in the pipeline, so please reserve your final judgment of the performance for later.

Security

• Traffic between the client browser and the Portal is encrypted using 128-bit server SSL.
  
  
• Traffic between the Proxy and the Portal is encrypted using 128-bit SSL. Proxies are identified by Portal using client certificate with non-exportable private key. This accomplishes mutual SSL-based identification between the Portal and the Proxy.
  
  
• “Last mile” traffic - between the Proxy and your application is not encrypted unless your application is configured to be accessible over SSL. Production release of HttpVPN will likely include Proxy signature into all requests received by your application. Once that's done, with a little bit of additional programming your app will be able to distinguish genuine requests coming from the Proxy, from malicious ones.