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.
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.
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.
- Traffic between the client browser and the Portal is encrypted using 128-bit
- 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
will be able to distinguish genuine requests coming from the Proxy, from malicious ones.