Proxy servers have garnered reputation as security products that ultimately undermine security. Designed to inspect network traffic for security purposes, proxies have become exceedingly difficult to maintain, and that complexity lends itself to security issues that create room for man-in-the-middle attacks. Proxies made sense when enterprises did not trust the cloud; now that enterprise collaboration and operations live in the cloud, treating the cloud as an outside entity in the way a proxy does make little sense.
Because our solution deploys within enterprise SaaS, Avanan is the only real-time cloud security solution that does not require a proxy. We have devoted tremendous resources to provide real-time protection within cloud services without the need for a proxy. Very early in our company’s development, we made the decision to eliminate the need for a proxy. While the reasons to do this might be obvious to anyone who has deployed alternate solutions, it might not be entirely clear why we made the decision.
A recent study, “The Security Impact of HTTPS Interception,” has brought to light one of the greatest drawbacks of the proxy, but it makes clear a fundamental truth: proxies are hard. They are hard to deploy. They are hard to secure. They are hard to maintain. Here are the reasons why we chose API-based connection as an alternate path:
1. Proxies are hard to secure.
The industry is saturated with proxies, which inspect communication between a client and browser in real-time. But by interrupting, inspecting, and re-encrypting internet traffic, proxies can inadvertently break Transport Layer Security (TLS) encryption that protects end-users browsing the internet. This sanctioned version of a man-in-the-middle attack commonly deployed in enterprise networks creates unexpected holes in enterprise security policies.
Canadian researchers from Concordia University in Montreal found that TLS connections interrupted by proxies became less secure. Their findings show that proxies are clumsily intercepting and breaking secure HTTPS connections between enterprise users and their cloud applications. In summary, they found that 62% of network traffic which passes through a proxy experiences a reduction in security, while 58% of middlebox connections have severe vulnerabilities.
“Across the board, companies are struggling to correctly deploy the base TLS protocol, let alone implement modern HTTPS security features,” the researchers claimed in “The Security Impact of HTTPS Interception." “Our results indicate that HTTPS interception has become startlingly widespread, and that interception products as a class have a dramatically negative impact on connection security” (2).
The middleware appliance companies analyzed in the study have been breaking TLS/SSL connections for decades as part of routine business, and yet the practice is still insecure. This could be a circumstance of an ever changing and vast security landscape—changing protocols, emerging vulnerabilities, and performance shortcuts (on the client and server side) breaking security—but the underlying issue seems to be symptomatic of the proxy technology itself. Simply put, security is lost in translation with proxies.
Although the research mentioned above examines perimeter proxies, the general problem with proxies (also known as middleware) is equally as urgent. The logistics of using a proxy are demanding, from managing encryption keys to keeping up with standards mandated by the web client or browser. While most CASBs use cloud-based proxies, they face the same challenges. Proxy technology is increasingly more fraught with issues, and this trajectory will only worsen as security and protocol requirements inevitably change.
High speed and traffic volume (desired and natural conditions of the internet) are an obstacle to proxy functionality. Additionally, vendors are partially to blame for shipping products that fail to support all types of connections and HTTPS encryption. Like much technology that was created without the burdens of the future in mind, the technologies propping up TLS traffic have become very complex, and proxies have failed to respond in proportion to those needs.
2. Decoding HTML is hard.
Once you have broken the encryption, you still need to decipher the HTTP conversation that is taking place inside. Even if there were no encryption, understanding the increasingly complex code that might be embedded in the web page or having to decipher cryptic calls to ever-changing APIs complicate proxy usage.
In a perfect world, HTML would be clean, and proxies would work. Unfortunately, reality persists: web interfaces are not clean HTML. Scripts and caching must be scraped, interpreted, and decoded. Proxies are forced to adapt quickly to changes in Salesforce’s interface and Google’s client, for example. How can security technology and personnel possibly interpret these inconsistencies in the middle?
It’s hard to balance decoding each SaaS provider’s protocols and keeping up with constant change. Like a DEA agent listening to a phone tap, proxies listen to the conversation between a SaaS and a web client, giving them limited visibility into security events. On the other hand, deploying within the SaaS gives an API-based security tool complete information—a full file, detailed permissions, and account information, for example.
3. Enforcing policy with proxies is hard.
Proxies attempt to make instantaneous decisions with limited information and virtually no context. Once something gets through the proxy, for example, it is too late to take action and remediate. Additionally, proxies only provide visibility into employee traffic, and what you see might not be reliable. It is impossible to enforce policy on anyone who is not in the organization, whether they are collaborators or hackers. When proxies do enforce policy, they can block, allow, or edit in the middle of the communication between the client and the SaaS they are using.
Even when policy is enforced, there is no guarantee that the proxy server security is foolproof. Simply enforcing policy can often break things. Take, for example, how proxy encryption at the field level might obfuscate a data set of 10,000 Contacts in Salesforce. Salesforce cannot decrypt the names of those Contacts, so performing a database sort in Salesforce would be rendered pointless or ruined.
Proxies are hard.
Proxies reduce speed, reliability, and ease of management. They add latency, require configuration changes (and worse, agents), and impede reliability—potentially bringing down cloud services at an enterprise in the event of proxy failure.
Because proxies are so cumbersome, we don’t do them. Instead, we connect directly via API to the most widely used enterprise apps to protect SaaS and enterprise collaboration from within. To eliminate the redundancy and incomplete security that are symptomatic of popular proxy solutions, the security community needs to improve network security and identity validation to eliminate the need for problematic proxies.
