Problems of SSL-VPNs

Posted by hob Mon, 10 Sep 2007 12:20:00 GMT
Today, many SSL-VPNs are used to access Webservers which are internal to a certain network, for example an enterprise or an organization.
In this way, the access is secure and authentication can be used.
When SSL-VPNs are used to access a Webserver, the HTTP datastream containing HTML, JavaScript, XML for Ajax, CSS or flash input data goes thru the SSL-VPN.
As the Webbrowser has to access the SSL-VPN over its TCP connections, and not the Webservers directly, the SSL-VPN checks the datastream and replaces links (URLs) by links to the SSL-VPN.
This is necessary, since normally the Webservers access directly from browsers in the internal network, and so the links in the Webpages point to the internal Webservers.

Now, as regards finding the links in the HTTP datastream, this is quite complicated, since links can be at different locations. There are also solutions where the link is dynamically built by the Webbrowser. This could be done, for example, by a JavaScript program. Also the JavaScript program could dynamically generate HTML pages containing additional links.
The JavaScript program runs in the browser on the client, and it may use variables which are only known to the browser, not to the SSL-VPN.

You can think of solutions where the SSL-VPN cannot find the link, and so is not able to replace the URL. This means, that these Webpages cannot be distributed over SSL-VPNs.

As this problem exists, what would be a possible solution to this problem?

A possible solution to this problem would be, that a so-called HOOK in the browser can be populated by a JavaScript function. The browser would send any URL, to which it wants to connect, over this HOOK. This HOOK could now check the URL, modify the URL if desired, or give a message-text preventing the browser from connecting to this URL but display the message-text to the user instead.

Of course, this HOOK, written in JavaScript, comes from a Webpage downloaded from the Webserver - or the SSL-VPN which sends this HOOK before sending the original Webpages from the Webserver.

These HOOKs may be nested, which would mean the browser calls several HOOKs one after the other until finally the browser uses the URL to connect to the server.
When HOOKs are nested, the one giving first should be the one which is processed as the last stage before the browser acctually makes the TCP connection.

When a JavaScript program registers a HOOK, it should get a handle in return. This handle would be needed if any JavaScript program wants to remove this instance of the HOOK later.

Modern browsers connect to a single Webserver with multiple TCP connections. There are also browsers which have tabs; each tab shows a single Webpage (made from multiple TCP connections) to the user.
So when a HOOK is set, this should be used for all TCP connections for a single browser tab.

The HOOK, which is programmed in JavaScript, has to be called by all TCP connections from the browser, i.e., from Java programs or Flash animation.

If this functionality is built into all Webbrowsers, SSL-VPNs can correctly distribute all Webpages, and SSL-VPNs would be less complicated compared to what they have to be today.

no comments |


Use the following link to trackback from your own site:

You must be registered in order to write comments. To register as a new user click here.

If you're already registered, please leave a comment here

Leave a comment

tp://')) %>
Powered by typo