Blue Coat

Addressing Encrypted Security Threats Inside SSL

Blue CoatBlue Coat ProxySG Appliances

Web applications (and their derivatives – IM, P2P, Web Services) continue to comprise the overwhelming majority of new applications being deployed across today’s distributed enterprises. Much of the new growth in Web application development is focused on business-critical applications. Furthermore, many of these applications and related components are hosted by 3rd parties or accessed over public infrastructure. Not surprising, the criticality and confidentiality of Internet-accessible applications has caused organizations to rely more heavily on SSL encryption.

SSL encryption was designed to create a trusted class of Web traffic – when the little padlock shows up in a browser, the traffic is deemed “secure.” This confidentiality has enabled businesses and consumers to take advantage of “anywhere, anytime, any user” encrypted connection to drive tremendous commercial exploitation of the Web. There is, however, a downside: encryption, the very thing that keeps prying eyes from SSL traffic, also makes it nearly impossible to see, understand, or manage that traffic. Indeed, in most organizations, port 443 (the designated port for SSL traffic) is not scrutinized– traffic freely and blindly flows in and out of the enterprise. This raises three sets of issues: first, IT lacks any control over this traffic; second, IT has no ability to protect itself from threats flowing in the encrypted traffic stream; and third, IT cannot prioritize and accelerate encrypted traffic – some of which may be mission-critical.

Most SSL traffic is, of course, benign and provides no threat to the organization. Further, much of it is key business traffic to business partners or to outsourced application providers. One example is salesforce.com, the online CRM provider, where all data is transferred using SSL technology.

On the other hand, users can use SSL technology to circumvent the usual policy controls. They can use SSL encrypted web email services (such as Yahoo! mail) to send out confidential information. They can also set up an SSL tunnel between the organization and their own home PC to transfer information and users have been known to use SSL to surf for inappropriate content on the web. The newer types of Spyware are now using SSL to get around spyware controls both for entering organizations and for sending out their information to the spyware control points. And, of course, often the worst attacks for individual users is phishing attacks where the user is fooled into entering their private information onto a bogus site and these are very often secured by SSL as it helps the user feel confident that this is a legitimate banking or finance site.

If an organization were to adopt a solution to resolve these issues, it would need to understand native SSL traffic flowing to external applications, be operationally affordable, not impede business (neither performance nor privacy), and be extensible and adaptable.

Unfortunately, most technology efforts to resolve these issues for unencrypted traffic have proved inadequate – none can “see” the encrypted traffic. While SSL offload or SSL VPN technologies can help organizations manage SSL traffic for applications that they control, there has not been a practical solution for “inside-out SSL.” In other words, traditional security and networking solutions cannot effectively protect users inside the corporate network from safely accessing applications and information outside the corporate network (e.g., Salesforce.com, employee benefits providers, and the wide variety of non-business-related applications their employees use).

IT organizations can overcome these limitations with intelligent proxy appliances that allow inbound and outbound encrypted traffic to be terminated – thereby enabling unprecedented visibility and context of the encrypted content. From there, proxy appliances can reinitiate the sessions according to the policies set by IT. Termination by a proxy is the only way to gain visibility and control of SSL communications. It provides a critical control point for protection (against viruses, worms, spyware, and phishing), policy (manage the who, what, where, when, and how of user/application interaction), and performance (cache, compress, and prioritize traffic).

Lastly though, organizations have to be responsible about use of this technology, understanding the privacy of the individual. The set up of the devices needs to understand the context of the SSL session before deciding whether to intercept the data stream. As an example, if you trust a certain site (or types of sites) then there is no need to intercept, for instance, data to and from salesforce.com or known banking and shopping sites (as defined by URL filtering categorization). Perhaps an organization allows users to access web-based email from work, but this should be intercepted. At this point, before carrying out any inspection, the user should be informed with a message that points out that the data is about to be checked for the their own good and the good of the organization. The user then has the option to cancel the request. The most dangerous types of SSL transaction are those to unknown destinations – the new phishing site that has just been created or just a plain IP address that is unknown and the organization’s efforts should be focused on those, as they hold the most danger.

Subscribe in a reader