Problem solve Get help with specific problems with your technologies, process and projects.

Are SSL-based portals sufficiently secure; and second, is there a risk posed by 'split tunneling'?

We would like to deploy applications to home users through Citrix Secure Gateway. Our information security group insists that a VPN is a better solution. Our goal is to deploy no software other than an ICA client, just allow those users access through a browser to some of our productivity applications such as e-mail, Office, etc. The reason that they insist on a VPN is due to split tunneling. Is this really a security issue (low risk) with this type of configuration, or is there a high risk of compromising our internal network? Can you give me a comparison of the two options and the risks of each?
Disclaimer: I'm not intimately familiar with the Citrix Secure Gateway product. From the available literature, it appears to be an SSL-based Web portal into the Citrix server, a perfectly reasonable thing to do. I will address your question in two parts: first, are SSL-based portals sufficiently secure; and second, is there a risk posed by "split tunneling" in this instance?

The answer to the first is easy: it depends. There is general agreement that the SSL protocol is basically cryptographically secure, when used at 128-bit key lengths and up. There are some risks if your server is poorly configured that may allow an attacker to force weak encryption to be negotiated; these can be avoided by ensuring that your server will only use strong encryption.

I believe that the principle weaknesses of SSL-based Web portals have more to do with how they are used, and with the typical responses of people using them. These issues are all about authentication -- of the server to the client, and of the client to the server. For the first, the certificate used to establish the SSL session is supposed to ensure the identity of the secured server, and prevent the possibility of a "Man in the Middle" attack. However, certificate problems are all too common (self-signed certs, expired certs, unrecognized signers), and users are conditioned to just click "OK" whenever a certificate alert pops up. It is the rare user indeed (and I'm not one of them) who will examine the certificate, notify the systems administrators of the problem, and refuse to use the service until the problems are corrected. Because of this, user behaviors may be exploited by attackers to compromise secure services. Secondly, user authentication to the server is often handled by a userid-password login. I shouldn't need to detail the weaknesses of simple password authentication here. Other user authentication mechanisms are available -- token or certificate-based -- but many organizations are unwilling to spend the time or money to implement and maintain them. Hence, SSL-based portals are frequently less secure than their users would like to believe.

There are several risks to a "split-tunnel" VPN, but it is not clear that they apply in this situation. Split tunnels generally refers to a case where some traffic is encrypted to/from a secure site, and other traffic goes in the clear to/from other sites. One risk is that the device handling the encrypted and non-encrypted traffic might be used to route traffic from the insecure network to the secure network, intentionally or inadvertently. Another risk is that users, who may not be aware of which traffic is being encrypted and which is not may inadvertently send sensitive information over the unencrypted connections. These risks are clearly greater when the VPN is a general-purpose IPsec VPN than when an SSL Web portal is being used. In the latter case, general routing of data is probably not possible through the portal, which is highly application-specific, and users are much more likely to be aware of which parts of what they are doing are secure and which are insecure.

I believe that SSL-based Web portals, configured and deployed correctly with appropriate authentication and user training, may be safely used to provide access to secure services.

This was last published in July 2003

Dig Deeper on Network Security Best Practices and Products

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.