The Benefits of SSL Content Inspection ABSTRACT SSL encryption is the de-facto encryption technology for delivering secure Web browsing and the benefits it provides is driving the levels of SSL traffic to new heights. But not all SSL traffic is benign and without the right security tools, SSL can be a blind spot into your network. Web filters that use URL inspection can only provide limited protection against malicious SSL traffic and so a more advanced approach that intercepts the SSL traffic allowing the filter to examine the traffic is fast becoming a critical requirement. This white paper reviews the different approaches that can be used to manage SSL traffic with Web content filters and discusses the limitations of legacy approaches compared to current techniques that can inspect the SSL traffic.
INTRODUCTION Every day more and more Web traffic traverses the Internet in a form that provides security and trust for users and is encrypted to prevent unauthorized eavesdropping. This traffic is encrypted with Secure Sockets Layer (SSL), a transport layer encryption protocol that protects data against unauthorized access. Current estimates indicate that 25% to 35% 1 of enterprise traffic is SSL, but this can be as high as 70% depending on the industry vertical. SSL has become the de-facto choice to secure Web-based transactions such as online banking, but the use of SSL has now extended into securing other applications such as secure email and providing tunnelling for corporate VPNs and extranets. According to Palo Alto Networks Application Usage and Risk Report 2, more than 40% of the 1,042 applications that were identified on enterprise networks in the study can use SSL or hop ports. The rise of cloud computing and applications is also delivering another uptick in SSL traffic. This white paper reviews the different approaches that can be used to manage SSL traffic with content filters and discusses the limitations of legacy approaches compared to current techniques that can inspect the SSL traffic. THE RISKS IN SSL TRAFFIC In many organizations SSL traffic passes freely in and out of the network because the IT organization lacks the ability to inspect and control SSL-encrypted traffic. However, not all content which is encrypted with SSL is benign. The content may be illegal, inappropriate or contain malware and other threats that could harm the organization s network and endpoint devices, impact user productivity and in some cases damage the organization s reputation. For further information about the risks of SSL, download Bloxx s white paper Protecting Your Network Against Risky SSL Traffic at http://bit.ly/1f4qnzm. Without visibility into SSL-encrypted traffic, IT lacks the ability to protect the organization and the reality is that SSL is a potential back door for inappropriate or malicious Web traffic. Fortunately, a Web content filter or Secure Web Gateway that has the ability to securely intercept and inspect SSL traffic can provide IT with the tools it needs to minimize the risks of SSL traffic. SSL PRIMER Secure Sockets Layer (SSL) was originally developed by Netscape Communications to provide security for Internet communications. SSL provides a secure channel between two endpoints, typically a client browser and a Web server, to provide protection against eavesdropping, forgery or tampering of the traffic. To provide this security, SSL uses X.509 digital certificates for authentication, encryption to ensure privacy and digital signatures to ensure integrity. Essentially SSL creates a secure tunnel between the two endpoints and the Web traffic is transmitted inside the tunnel. The encrypted traffic is called HTTPS and uses port 443 to communicate between the client browser and the Web server; unencrypted HTTP traffic uses port 80. It is worth noting that although SSL is primarily used to secure HTTP traffic, SSL was designed so that it could provide security for many other application protocols that run over TCP.
THE CHALLENGES OF MANAGING SSL TRAFFIC Traditionally, SSL has been used to provide security and privacy for confidential information or transactions, for example online banking, e-commerce, and so on, but as previously mentioned many more Websites and Web applications are now moving towards HTTPS as default. However, although HTTPS provides increased security and minimizes the risk for users and organizations, it also creates a blind spot which can allow users to access inappropriate or productivity impacting content and a back door into your network that cyber criminals and malware authors can effectively exploit. A gateway level Web content filter or Secure Web Gateway is typically used to proactively control the Web content that users are allowed to view, typically by checking the URL being requested against a categorized database of URLs. This is easy and straightforward to do when the request is being made using HTTP. However, when the request is being made using HTTPS, only the top level domain, or in some cases its related IP address for the Web page being requested is visible to the Web filter. For example if www.google.com/mail is being requested, then the Web filter can only make a decision to block or allow on www.google.com. This makes enforcing a granular filtering policy extremely problematic for HTTPS traffic. With more sophisticated Web filters that analyze and categorize content of the page being requested in real-time to determine the type of content and to scan for malware, the encrypted nature of the traffic means that these additional layers of filtering cannot be used. In practical terms, this could mean that when a user deliberately or accidentally accesses inappropriate or illegal content using HTTPS, the Web filter will be unable to determine the type of content being requested and may simply allow access. This could lead to serious consequences for the employee and the organization if, for example, illegal content such as child abuse images or racial hatred content is being accessed. In addition, if an exploited Website containing a malware payload is accessed using SSL then the encrypted page cannot be scanned by the malware detection engine leading to the risks of networks and endpoints becoming infected with malware. A REAL-WORLD SSL EXPLOIT Criminals can exploit the trust that users put in SSL to create a fake web page that will trick victims into providing confidential information. In one example, criminals had hacked into the website of the Malaysian Police force to set up a fake PayPal page. The page used the valid SSL certificate from the site to trick potential victims into thinking that the site was legitimate so that they provided confidential information such as usernames and passwords. Most users had assumed that after seeing HTTPS and a green padlock in their browser that the site was legitimate and safe without checking that the URL matched the site in front of their eyes. For example if the site that a user is connecting to is Paypal, then the address needs to begin https://www.paypal and not https://www.paypalnow, or https://www.fakepaypalsite. The last URL is obviously a fake, but many people will put absolute trust in the green padlock symbol. The SSL certificate in this instance was valid but the certificate authority, in this case Symantec, had not revoked the certificate through a Certificate Revocation list or by using on-demand OSCP responses.
BASIC APPROACHES TO MANAGING SSL A draconian approach to minimizing the risk of SSL traffic might be to simply block all SSL traffic using a firewall rule, or to block all SSL traffic with a Web filtering policy, only allowing access to specific web sites or pages. However, with the rapid growth of the Web and the growing use of SSL, this approach has become unsustainable and would likely create a deluge of IT support calls requesting access to specific sites. A more effective and advanced approach is to use SSL certificate based filtering. In this approach, the Web content filter attempts to validate the host name or certificate name from the Web server that is being accessed, so that the URL can be validated against the URL database. This approach has some advantages in that no changes are required to be made to client browsers and a filtering policy can be applied if the URL is obtained. However, there are a number of limitations to SSL certificate filtering. These include the fact that the user will only see a page cannot be displayed error and so will be unsure if this is a filtering policy restriction or a network, website or browser error; filtering relies on only the URL and not the page content; and malware cannot be scanned and blocked. Therefore, the only practical and sustainable approach is to provide a mechanism that allows your Web content filter or Secure Web Gateway to intercept, decrypt and analyze the SSL traffic. A MORE SOPHISTICATED AND SECURE APPROACH TO MANAGING SSL To allow proactive management of SSL, it is necessary to look inside the secure tunnel and examine the encrypted traffic. One effective way to deliver this capability is deploy a Web filter or Secure Web Gateway that is able to intercept and decrypt the SSL traffic. To achieve this, the Web filter creates a secure connection between the client browser and the Web filter, and decrypts the SSL traffic into plain text. Then, after being analyzed the traffic is re-encrypted and another secure connection is created between the Web filter and the Web server. This means that the Web filter is effectively acting like an SSL proxy server and so can both intercept the SSL connection and inspect the content. Bloxx SSL Intercept (SSLI) is used to provide this capability in the Bloxx Web Filter and Secure Web Gateway. SSLI operates by temporarily capturing the SSL traffic so that the Web page being requested can be analyzed, categorized and filtered before it is delivered to the client browser. The unencrypted traffic is also passed to the malware detection engine to identify and block malicious traffic. In order to provide further security, the SSL certificate from the Web site in question is checked against a list of valid certificate authorities. This is an extra check on top of those that are performed by Web browsers. The key difference is that this check is enforced at the gateway and can prevent users from proceeding to sites with invalid certificates, whereas browsers will let them access these sites. It also means that if a browser s list of trusted Certificate Authorities (CA) or Certificate Revocation List (CRL) are out of date, that the gateway will still catch the invalid certificate and block access to the site. This level of functionality is available in Bloxx Secure Web Gateway and does not require decryption of SSL traffic. This combination of safeguards increases security levels on your network and protects users from inappropriate or illegal content. Bloxx SSLI provides SSL traffic inspection and filtering in any deployment, regardless of where your Bloxx filtering appliance is situated on your network. SSLI intercepts SSL requests, and checks the validity of all server, intermediate and root server certificates. These certificates are then replaced by a spoof certificate. The spoof certificate is generated dynamically on the Bloxx appliance and signed by the Bloxx CA certificate, signifying the fact that the page is being delivered by the Bloxx Web filter, and not the remote Web server. To the endpoint browser however, the certificate appears as if it is from the remote website. This approach allows SSL traffic to be securely intercepted, decrypted, analyzed for content and potential security threats. There are a number of significant advantages to this approach, coupled with implications for the network in question, and several options for certificate deployment. These are discussed in the following sections in further detail.
HOW BLOXX WEB FILTERING WITH SSLI ENHANCES SECURITY There are a number of significant benefits that are delivered by using the Bloxx Web Filter or Secure Web Gateway to manage SSL traffic. Confidential Information Remains Secure A principal concern with intercepting and decrypting SSL traffic is the security of the data being decrypted. After all, the HTTPS traffic has been encrypted because of its sensitive nature, and security of data such as bank account details is paramount (especially from the perspective of the end user). In order to preserve the security of sensitive data, the Bloxx filtering appliance decrypts the traffic but it does not log or store any plain text data. Protecting Sensitive SSL Traffic There will be specific sites that use SSL (such as banking or healthcare sites) where you do not want the Bloxx filter decrypt and inspect the traffic. To allow this, the Bloxx filtering appliance allows you to easily select specific categories of SSL traffic that you may consider particularly sensitive so that any related SSL traffic remains encrypted. This capability of decryption exception ensures that the sensitive SSL data involved remains completely encrypted, but still allows the validity of the SSL certificate to be verified. SSLI and Dynamic Real-Time Categorization The combination of SSLI and Bloxx s patented real-time content categorizer, Tru-View Technology (TVT), provides an effective method of categorizing and filtering SSL content whilst applying the appropriate filtering policy. Once the requested Web page has been retrieved, SSLI decrypts the content and passes this to TVT for analysis and categorization. In addition, the page is also passed to the filter s malware scanner to detect for viruses or other potentially harmful content. This means that the filtering policy for SSL traffic is applied based on the content of the page, not just the URL being requested. So for example, if the SSL page contains adult content, then TVT has the ability to categorize and block the page. Real-time content analysis and categorization coupled with the ability to decrypt and scan content for harmful malware programs ensures that your network is protected from newly emerging security threats and that your users and organization are further protected against accessing inappropriate or illegal content Securing End Points Increasingly, the types of malware programs mentioned above are being hidden within SSL traffic. Without decrypting SSL, how will you minimize the risk of infecting end points? The Bloxx Web Filter can help increase network security by checking for these potential threats hidden in SSL traffic before they reach end points. The Bloxx content filter decrypts the secure Web content which is passed to the filter s malware detection engine, enabling the content to be scanned and assessed for malicious code before it is passed on to the endpoint.
DEPLOYING BLOXX FILTERING WITH SSLI AND SSL ROOT CERTIFICATES To ensure that the browsing experience of users is not impacted when you deploy the Bloxx Web Filter or Secure Web Gateway to inspect SSL content, it is recommended that you install a new SSL Root Certificate on end point devices. It is worth highlighting that this is not an issue that is related to the way SSLI operates, but is a result of the way the SSL certificates have been designed to prevent tampering or other malicious activities. As previously mentioned, SSL uses X.509 digital certificates for authentication during an SSL session. When deployed to intercept SSL traffic, the Bloxx filter needs to become a Certificate Authority (CA) to ensure seamless and uninterrupted operation of SSL. To achieve this, To ensure that the browsing experience of users is not impacted when you deploy the Bloxx Web Filter or Secure Web Gateway to inspect SSL content, it is recommended that you install a new SSL Root Certificate on end point devices. It is worth highlighting that this is not an issue that is related to the way SSLI operates, but is a result of the way the SSL certificates have been designed to prevent tampering or other malicious activities. As previously mentioned, SSL uses X.509 digital certificates for authentication during an SSL session. When deployed to intercept SSL traffic, the Bloxx filter needs to become a Certificate Authority (CA) to ensure seamless and uninterrupted operation of SSL. To achieve this, the certificate provided by the Web server being accessed is automatically regenerated by SSLI. The name of the remote server and its altname are not changed. To achieve this seamless operation, all SSL clients must use the Bloxx SSL Certificate (or an alternative one that you generate) as a trusted Certificate Authority. To achieve this seamless operation, all SSL clients must use the Bloxx SSL Certificate (or an alternative one that you generate) as a trusted Certificate Authority. INSTALLING A ROOT CERTIFICATE To prevent warning and exception messages being displayed in users browsers, it is necessary to install a Root Certificate on client devices. There is a misplaced belief that doing this could expose organizations to additional security risks. However, it is important to note that when you create your own root certificate on the Bloxx filtering appliance, you are the only one with access your private key. Bloxx does not have access to this, and as such a potential hacker would need to be able to compromise the Bloxx appliance in order to capture sensitive information. This is due to the fact that no clear traffic travels over the network, but remains within the Bloxx filtering appliance. Installing the Certificate on End Points There are two possible approaches for installing a certificate on a client device. A default Bloxx CA certificate can be automatically generated, or alternatively it is possible to upload your own certificate, where you have the ability to control the issuer, subject, and expiry date. The auto-genetrated Bloxx certificate is valid for 10 years. Installing the Certificate on Wireless End Points For wireless devices such as tablets and smartphones, it is recommended that you place a link to download the Bloxx CA certificate (or whichever certificate you choose to use) on your Wi-Fi landing page.
DECRYPTION EXCEPTIONS A decryption exception means that SSLI will no longer intercept the secure traffic, but will simply verify that a site s security certificate is valid. There are two situations where you may require SSL traffic to remain encrypted. The most common use case is to ensure that personal details or highly sensitive data remain completely encrypted. This means that the Web filter cannot analyze and categorize traffic but will simply verify that a site s security certificate is valid and perform non-content-based filtering using the domain or IP address of the remote server, or CN and altnames from the certificate The other use case is when the SSL client is incompatible with SSLI because it does not provide a way to trust the Bloxx CA certificate. CONCLUSION In this white paper we have discussed several ways in which intercepting SSL traffic can increase network security, reduce the risk of inappropriate content being accessed and allow content filtering based on the content of the secure Web page being requested. The recommended approach to implementing SSL content inspection on your network is to consider the security implications from both perspectives. If SSL content inspection is not implemented, risks to your organization include allowing access to inappropriate content, increased risk from SSL anonymous proxies, and exposing your network to harmful malware which can compromise confidential information. On the other hand, the minimal possibility of your SSL traffic being compromised through the Bloxx content filter may present the lesser risk. When making use of SSLI capabilities, you have complete flexibility to select which sites to decrypt, thus creating the option to completely customize the way you filter different types of SSL traffic. For example you could choose to tunnel banking sites, but intercept all other SSL traffic. REFERENCES 1. SSL Performance Problems NSS Labs Analyst Brief, https://www.nsslabs.com/system/files/public-report/ files/2013-06%20ab%20ssl%20performance%20problems%20130605c.pdfsdfsdrtrfsdf 2. Palo Alto Networks, Application Usage and Risk Report (7th Edition, May 2011). http://media.paloaltonetworks. com/documents/application_usage_risk_report_2011-05.pdf t. 617 924 1500 e. info@bloxx.com w. www.bloxx.com Copyright 2015 Bloxx Ltd. All rights reserved. No part of this document may be reproduced by any means nor translated to any electronic medium without the written consent of Bloxx. Specifications are subject to change without notice.