In this way, the access is secure and authentication can be used.
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.
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?
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.
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.
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.
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