SSL VPN Remote Access is Convenient but Not Secure
by Eirik Iverson, Product Management
SSL VPN security is equivalent to holding private meetings in a crowded restaurant whereby other diners are required to voluntarily ignore the conversation and those in it are blind-folded and required to recognize the voices of their colleagues to prevent outside influences. Web browser security flaws, lack of browser and computer policy enforcement, computer malware, and dependence on end-users recognizing man-in-the-middle attacks make SSL VPN a poor choice for organizations with anything worth stealing or manipulating.
Porous Compartmentalization within Web Browsers Undermines SSL VPN
Researchers at DefCon 2009 recently published a comprehensive study on the unexplored opportunities for malware makers on attacking the interoperability of applications and their plug-ins, particularly web browsers. I recently posted an article on this blog articulating the nature and significance of these risks that indicate that web browser vulnerabilities are at least one or two orders of magnitude more numerous than previously thought. In short, the data interactions of any single web browser tab or window ought to be private and unadulterated by any other software object within the web browser. It isn’t so and will not be for a long time. Note, malware within a web browser is and manipulates other software objects.
Many information security practitioners recommend the use of two or more separate web browser applications to better compartmentalize web activities from others until the promise of web browsers spawning separate processes per tab/window is convincingly demonstrated over time. This slight digression raises another point about endpoint policy enforcement and authentication (two sub-sections below).
SSL VPN More Vulnerable to Malware Infested Computer Risks
But malware on a computer with IPSec or any other form of VPN is just as susceptible, right? Yes and no! Yes, malware intended to steal information can do so on either. However, with SSL VPN, the malware need only adapt to eavesdropping on web communications, whereas with IPSec VPN the malware must do so for all relevant applications. Similarly, altering or conducting additional activities is easier too. Further, an SSL VPN session can literally be hijacked, such that remotely controlled malware can continue to covertly use it without an end-user’s knowledge.
SSL VPN End-user Convenience versus Enterprise Security
More important than the above comparative susceptibility, however, end-users can use ANY computer to launch an SSL VPN session. Detecting malware after infestation, particularly on machines that run with local admin rights, is nearly pointless with the increased use of 3rd generation Rootkit based malware. Cyveillance recently found signature-based tools failed to detect over 71% of the malware samples they gathered in the wild that were less than a month old to test. I recently wrote another article concerning the data leak risks to organizations allowing employees to work from employee owned computers.
Man-in-the-browser malware is among the toughest to detect and deter. Sophisticated attacks from compromised or malicious websites, for example, employ public key cryptography to effectively obfuscate their malware attack code as it enters or leaves a computer (e.g., “Lucky Sploit” Malware ToolKit). If the attack code limits its operations to within the web browser, the chances of its detection are far, far less than if it tries to ‘venture out of the browser’. So SSL VPN communications are easier for malware to compromise than IPSec.
SSL VPN vendors offer browser plug-ins to assess the status of security software on a computer. This says nothing about the state of the computer an hour, day, or a year earlier. With today’s stealthy malware, endpoint health assessment must ultimately be a continuous, cradle to grave, practice. Employees understandably would have reservations about their employers continuously monitoring an employee-owned computer.
SSL VPN Must Require a Dedicated Web Browser that is Site-Locked
Cross site scripting attacks, for which no near term, practical defense yet exists, utterly confuse web browsers and their end-users such that they do not know whom they are communicating. An organization that must use SSL VPN can enforce policies that site lock a web browser to one or more SSL VPN gateway IP addresses. Malicious and mischievous end-users can circumvent policy enforcement tools not specifically designed to prevent this, however. Browser applets cannot do so continuously.
SSL VPN vendors could theoretically employ web browser applets that rigorously interrogate a web browser seeking an SSL VPN session to determine whether or not it truly is the designated web browser. Frankly, I don’t know if the vendors actually offer such a capability yet, or whether this proves effective. And keep in mind, the article reference above concerning browser/plug-in/library object interoperability, as well as object integrity shortcomings (not all web browsers provide for digitally signed validation of software objects), SSL VPN plug-ins and other software objects present and are subject to other problems.
Regardless, SSL VPN gateways do not effectively authenticate computers (not to be confused with end-user authentication). So, if one ignores the risks from the host computer, dedicated, site-locked web browsers can reduce risks.
SSL VPN Depends on End-users Properly Responding to Man-in-the-Middle Attacks
Indirectly, the preceding sections imply man-in-the-browser attacks, whereby malicious software objects unknowing operate within the browser to eavesdrop, manipulate, and even hijack a session. Man-in-the-middle attacks, however, generally exploit end-user ignorance. Most end-user click on a web browser’s continue button when a prompt says the ‘certificate for this server is invalid’, trying to alert the end-user to the attack. Like opening email attachments, organizations can tell end-users not to do so, but they do. And, they will click that ‘continue’ button too. Endpoint policy enforcement tools can ensure end-user discretion is eliminated. But then, we return to the challenge of the SSL VPN gateway authenticating the browser, the computer, and the end-user too.
Side-story: Years ago, I showed a marketing colleague something on my computer display. It was a prompt from my web browser, alerting me to some web server’s invalid certificate. She agreed to make a quality screenshot of it. Almost immediately, she questioned why her display was so different from mine. She had clicked ‘continue’ on the prompt and said she always does so. The poor thing then endured one of my lectures.
Remember, end-user authentication is essential and most forms in use are vulnerable to man-in-the-middle attacks. One-time pass code systems authenticate the end-user but not the SSL VPN gateway. Out-of-band authentication (e.g., cell phone text message) is a worthy mechanism if it at least implicitly authenticates the SSL VPN gateway too. Client VPN software completely eliminates dependence on end-users making the correct security choice.
SSL VPN Fine Grained Filtering Compared to IPSec and Local Ethernet Switches
SSL VPN gateways perform proxy operations insofar as remote access user computers do not communicate directly with anything on the other side of the SSL VPN gateway. This proxy server functionality benefits organizations because it can filter out risky content such as HTML ‘put’ arguments that would try to write something to a server. Such filtering reduces the exposure of important servers to the endpoint population. Most SSL VPN gateways include such capabilities. As to what percentage of deployments actually makes significant use of it, I cannot say.
One might ask, however, how many organizations employ a proxy server between local end-users and their important servers? After all, Ethernet switches do not do so. Any endpoint, remote or local, is a potential malware infested threat to all enterprise servers. How commonly do they internally deploy an SSL VPN gateway for this purpose? Are SSL VPN gateways sufficiently compatible with ALL of the enterprise applications employed? Doubtful!
Enterprise content filtering is becoming more and more comprehensive. They perform both proxy and non-proxy filtering of traffic. Does it make sense to effectively manage two sets of proxy servers: one for local endpoints and SSL VPN gateways for remote computers? Deploying a single system for both local and remote computers is considerably more practical. From this perspective, there are operational savings from using a layer 2 client VPN solution for remote access to protect important servers from the risks from client endpoint exposure.
SSL VPN Offers Lower Operations Costs
Presumably, SSL VPN does not require installation of persistent client software, sparing organizations of installation and software testing requirements. However, SSL VPN vendor value-add capabilities, which help make their data sheets and marketing materials look impressive, often do install persistent client software. When features require local admin rights for first-use, then persistent client software is in play, which can fail, be exploited, and must be patched/updated from time to time. I wrote of this in a white paper called the “Case for Agent-based NAC Solutions”. This tends to undermine the argument that SSL VPN doesn’t require client side testing and life-cycle support but Client VPN software does.
Client VPN, however, always requires software installation. I can appreciate the dilemma of small medium businesses lacking a centralized software distribution and configuration management system.
However, those that do have them, such as federal organizations that must comply with Federal Desktop Core Configuration (FDCC) requirements and large commercial organizations can push out software installations quite easily.
So, it comes down to known operations costs versus unknown security losses. SSL VPN represents a massive data leak risk. Yet, with the inability to detect malware infestations, man-in-the-browser attacks, and man-in-the-middle attacks, how would an organization plausibly know what data they are leaking daily, particularly if unknown computers are used for SSL VPN connections? No easy answer, so turn this perspective around to a basic security question: do you know where your data and documents are, and where they’ve been? Many security practitioners argue if this answer is grossly unknown, then one cannot assert having good security. SSL VPN exacerbates this challenge.
Do SSL VPN Security Weaknesses Matter to Organizations?
The primary purpose for SSL VPN deployment is to provide low operations cost remote access to organization employees so they can access and input data so their employers benefit from increased productivity. Ideally, organizations also consider security a primary factor in SSL VPN deployment, seeking private communications without tampering by outside parties and reduced exposure of the application servers to malice. Given that most of my concerns regarding SSL VPN security have been expressed for years and SSL VPN continues to be so widely employed, is SSL VPN security really a priority among IT decision-makers, or are those professionals really unaware of them?
If One Must Use SSL VPN, Invest in Computer Protection
Blue Ridge offers several computer protection products, AppGuard, AppGuard Enterprise, and EdgeGuard, and a managed security service called Managed EdgeGuard. They protect computers from malware attack code of all ages whereas anti-virus/spyware products found on nearly all enterprise computers are only effective at stopping malware over a month old and used extensively by cyber criminals in the wild. Equally important, from both the end-user and enterprise administrator, they are considerably more ‘usable’ than alternatives from other vendors.
Secondly, encourage your end-users to use one web browser for SSL VPN, and FOR NOTHING ELSE. Consult your SSL VPN provider for its most robust mechanisms for rejecting other web browsers. The dual browser strategy reduces the risks from man-in-the-browser threats.
For More SSL VPN Risk Mitigation, Invest in Computer Protection AND Control
The above recommendation depends upon the voluntary compliance of end-users to NOT use the SSL VPN dedicated web browser for OTHER purposes. Organizations can eliminate this dependence with EdgeGuard and Managed EdgeGuard, which can lock-down web browsers in the manner implied above, even when end-users operate their computers with local admin rights.
The EdgeGuard solutions can also provide IT personnel considerable operational awareness into the state of their endpoint population to identify and quantify their risks. Further, EdgeGuard can then enforce the subsequent security configuration policies from these audits to dramatically reduce endpoint exposure to attack and data leaks. They can also assess and remediate numerous and common problems in 3rd party security software products. Studies typically reveal that one out of every four enterprise computers are at greater risk because a security software product is out-of-date, disabled, or otherwise underutilized. EdgeGuard identifies and corrects these issues to maximize the value of these investments and minimize endpoint risks. EdgeGuard can also snuff-out unwanted software applications (e.g., peer-to-peer, rogue instant messengers, etc.), assess/implement Microsoft security patches, as well as conduct custom script based assessments and configuration changes uniquely required for an endpoint population.
EdgeGuard is designed NOT to replace typical endpoint management tools but supplement them so organizations do not have to buy into the expensive and sticky all-in-one promises of the big vendors. Consequently, IT personnel do not have to abandon their proficiency with their familiar tools and learn how to use something else.
As much employee work is conducted on employee-owned computers, employers are justifiably concerned about the security of these computers. Some employees are opposed to their employer managing EdgeGuard agents on their home computers but are more open to a trustworthy third party, such a Managed Edgeguard.
For Organizations with Much to Lose, Little to Spend, and a Need for Truly Secure Remote Access for Telecommuters/Teleworkers
Supplementing the above endpoint security solutions, Blue Ridge offers the BorderGuard VPN product and a Managed VPN managed security service to deliver highly secure and end-user friendly remote access. These solutions have been deployed world-wide for over a decade.
They employ IPSec VPN technology that employs a proprietary key exchange process, which is largely responsible for the lack of any reported vulnerabilities or security breaches for over a decade. If one goes to the National Vulnerability Database and searches on the keyword ISAKAMP, an acronym associated with all other IPSec offerings, no other vendor can boast such a record.
The key exchange process, called security enhanced Internet key exchange (SE-IKE) envelopes the entire key exchange process within mandatory mutual public key authentication, which literally double encrypts each key exchange message with two different RSA keys. Consequently, SE-IKE is immune to protocol attacks, man-in-the-middle attacks, and others, whereas all other IPSec and SSL VPN offerings are not. Note, most IPSec deployments of other vendor offerings utilize shared secret keys, which expose their VPN to virtually undetectable man-in-the-middle attacks if just one of their unpatched VPN appliances/routers is compromised. Unlike SSL VPN, Blue Ridge VPN solutions eliminate dependence on end-users making correct security decisions.
These BorderGuard solutions can use either the PKI credentials facilitated by their central management system or utilizes 3rd party PKI credentials such as DoD CAC and HSPD-12.
BorderGuard remote access differs considerably from SSL VPN and other IPSec offerings in another prominent ways too. Each remote access connection or tunnel is a truly layer 2 connection whereas SSL VPN and other IPSec offerings are not. Any application/communication protocol that can traverse Ethernet, does so problem-free through a BorderGuard tunnel, which is like a secure Ethernet extension-chord. And lastly, BorderGuard tunnels add considerably less bandwidth, latency, and jitter overhead. Case in point, BorderGuard tunnels secure satellite VOIP communications among Iraqi ministry and other government facilities. Other well-known products had added too much overhead, leaving only BorderGuard solutions operational.
Related Articles:
Flaws in Web Browser Security Undermine SSL VPN Security
PC Malware Driven Security Breach Disclosures—A Case of Worms
Data Leak Prevention and Network Access Protection (NAP)
Websites Unknowingly Attacking PCs
Is a PC Using a Limited User Account (LUA) Safe from Drive-by Download Attacks?
Business Protection from AntiVirus-Failure Caused Fraudulent Bank Transfer Losses



September 18th, 2009 at 1:17 pm
[...] View original post here: SSL VPN Remote Access is Convenient but Not Secure [...]
September 25th, 2009 at 4:13 am
[...] Russian Roulette & SSL VPN Remote Access Telework [...]
September 25th, 2009 at 5:41 am
[...] Russian Roulette & SSL VPN Remote Access Telework [...]
September 30th, 2009 at 10:31 am
[...] Secure Remote Access to Your Mac using SSH – Part 1 Mac 101 | Mac 101Russian Roulette & SSL VPN Remote Access Telework [...]
October 6th, 2009 at 9:27 am
[...] ssl vpn remote access is convenient but not secure [...]
October 30th, 2009 at 9:12 am
I actually like SSL VPN Remote Access Software. I find that it gives me a flexible and secure way to extend networking resources to virtually any remote user with access to the Internet and a web browser. Remote access based on SSL VPN delivers for me a secure access to network resources by establishing an encrypted tunnel across the Internet using a broadband connection. I don’t think I have had any trouble with my SSL VPN as of yet. If someone can tell me their problems, maybe I can help fix them.
November 2nd, 2009 at 2:16 pm
The concern regarding SSL VPN has more to do with the lack of security of the endpoint and the web browser than the cryptography of SSL VPN. Once an SSL VPN tunnel is established, typically using AES 256 and SHA-1 for encryption and data integrity, there’s a fairly robust tunnel. One can take issue with the key exchange process and the dependence of end-users to recognize a man-in-the-middle attack.
Also, I wouldn’t fault SSL VPN for significant connectivity issues. Yes, some applications such as VoIP or other network/data layer protocol intensive activities can be problematic. But, these applications do not represent the majority of SSL VPN use in my humble opinion. And, I believe many SSL VPN vendors offer IPSec plug-ins, for web browsers, when there’s a need to overcome such issues.
The very convenience of SSL VPN underscores one of its fundamental weaknesses. As ANY PC can be used, then even the most malware infested PC can be used, which could leak any information that passes through the PC. In contrast, an IPSec VPN tends to be limited to PC’s that are managed by an organization. Such PCs tend to be considerably less likely to be malware infested.
Consider Banking Trojans stealing money from organizations, the newer, sophisticated ones are usually discovered after someone notices fraudulent transfers, after-the-fact. At that point, someone, frequently a forensics technician, conducts a thorough examination of the endpoints, and finds the Trojans. The existing anti-virus/spyware had not. Now, tie this back to SSL VPN remote access. What corresponding indicator would let an organization know that sensitive information is leaking from the organization? In other words, how would one ’see’ problems with SSL VPN in the context of data leakage?