Managing SSL Traffic: An examination of SSL and how to secure it

Managing SSL Traffic: An examination of SSL and how to secure it

Much has been written about the SSL/TLS encryption protocol in the wake of events that include the Heartbleed vulnerability, Apple OS bug and others. The SSL/TLS protocols were created to increase Internet security, however vulnerabilities such as the Heatbleed bug and exploits like the Zeus botnet, which used SSL to upgrade after its initial infection, are undermining users confidence even as organizations struggle to secure their data in an increasingly treacherous Internet environment. The popularity and adoption of mobile devices in the workplace has added to the complexity introducing multiple platforms and applications that introduce compatibility challenges. After the Wikileaks incident, where highly sensitive NSA (National Security Agency) documents were leaked to the public, the use of SSL/ HTTPS encryption on the Web grew by 60%, according to one report. The wide availability of tools and kits that enable SSL communications made it easy for websites to embrace it. However, its growing use and the vulnerabilities within the software used to deploy it, have dramatically increased the number of cybercrime attempts to exploit SSL to steal data. This rise in SSL exploits is aided by a combination of factors, including the enduring impression among Internet users that SSL/HTTPS sites are safe, and the fact that many security solutions are unable to efficiently inspect SSL traffic, particularly when it communicates via UDP ports used to send streaming data. What is SSL/TLS? The Secure Socket Layer (SSL) protocol was created in 1994 to provide security for the increasing amounts of private and sensitive data being transferred over the Internet. It was designed originally to protect communications between applications and computers, by providing an encryption layer to run under HTTP Web traffic, expressed as HTTPS indicating its SSL status. In 1999, the Transport Layer Security (TLS) protocol was introduced to increase security across servers, networks and computers, and apart from some technical process variances, the two serve the same purpose. They both encrypt outgoing data that is then decrypted once it reaches its intended destination. 1 2 3 4 5 Client/ Browser Browser requests secure connection Server sends SSL certificate Private key is encrypted and sent with public key to server Server verifies encryption of future transmissions All transmissions now encrypted 5 How SSL Works 1 2 3 4 Server

The SSL encryption process is insured by a public key that encrypts data at its point of origin and a corresponding private key, which is required to decrypt data once it reaches the recipient. In between this transfer there are a number of handshakes to assure that each side of the communication is who it claims to be. The authenticity of the public key is verified by a digital certificate issued by a certificate authority (CA), a third party that verifies that the holder of the public key is the named subject of the certificate. This enables others in the transfer process to rely on the validity of the private key that corresponds to the public key. There are many Certificate Authorities, responsible for verifying root certificates including VeriSign, DigiCert, Network Solutions and others. In 2005, the Certificate Authority Browser Association (CAB) created new guidelines with more stringent SSL requirements resulting in an Extended Validation (EV) SSL certificate. Achieving an EV SSL validation means that a website has undergone extensive human review and meticulous documentation checks confirming ownership and authenticity. Organizations that deal with highly sensitive or regulated data were quick to pursue this elevated level of validation, though it takes longer and costs more to acquire. SSL/TLS adoption is increasing Although there have been various campaigns to require all Web traffic to be encrypted, according to Gartner, For most organizations, SSL traffic is already a significant portion of their outbound Web traffic and is increasing. It represents on average 15% to 25% of the total Web traffic, with strong variations based on the vertical market. 1 In the same report, Gartner recommends that organizations, Quantify your current encrypted traffic mix, and anticipate a 10% to 20% yearly growth when evaluating future network security purchases. 1 One reason the use of SSL protocol will continue to grow is because of its ubiquitous adoption by large enterprises including SaaS platforms such as SalesForce and DropBox, social media applications like Facebook and Twitter, and popular public clouds such as Amazon.

Websites that use SSL are easy to spot as they have a padlock icon and green color in the URL address bar. Typically, seeing the SSL icon has given users confidence that they can pay their bills, file taxes, purchase items, view their health records, renew their car registrations and perform countless other tasks, without worrying that their private information will be exposed. Unfortunately, a wave of new data breaches threaten to undermine that confidence. SSL exploits are also are the rise While the growth of SSL use may bring some peace of mind to Internet users, the percentage of cybercriminal attacks using SSL is growing even faster than its adoption by organizations. According to Gartner, in 2017, more than half of the network attacks targeting enterprises will use encrypted traffic to bypass controls, up from less than 5% today 1. Zeus P2P botnet using SSL Streaming data that s transferred via UDP data channels using SSL are one way exploits can occur, leveraging the users confidence and directing them to fake sites with authentic-looking SSL certificates. The Zeus botnet, which made its debut in 2007, was designed to steal banking information and it 1 Gartner, Inc. Report. Jeremy D Hoinne, Adam Hils. Security Leaders Must Address Threats From Rising SSL Traffic. December 2013 initially infected networks using email phishing techniques, dropping recipients who clicked on the imbedded link to infected websites. Once in the network, the Zeus Trojan deposited a bot designed to communicate with command and control (C&C) outside via TCP ports. Since then, Zeus has stayed active and changed its tactics to take advantage of less secure and hidden UDP ports, using peer-topeer applications to communicate outside. This powerful Trojan was recently able to upgrade itself using a UDP peer-to-peer SSL data channel, injecting a critical update package that many standard security solutions missed. Apple OS SSL vulnerability In addition to exploits that rely on port-evasive techniques, flaws within SSL are equally dangerous. The Apple ios bug was first revealed in February 2014 when a fix for it was released. It affects ios versions prior to 7.0.6 and Mac OS X (it has been confirmed on OS X 10.9.1). Though it did not receive extensive publicity at the time, it is actually a very serious vulnerability that allows a hacker to create a website mimicking a legitimate SSL site, similar to the Zeus Trojan tactics. Users who respond to a legitimate looking link embedded in an email would arrive at a site and see the trusted CA icon verifying the root certificate, and think they are on a known, legitimate site. The hacker who created the bogus site can now easily obtain login credentials and the rest is data loss history. Most analysis of the issue indicated that the vulnerability was only of concern on untrusted networks in public places like hotels, coffee shops or public WiFi. This was because a hacker would have to get elevated network privileges in order to redirect users from the real site to the fake one without their knowledge, and getting those privileges would only be possible on untrusted networks. However, though elevated network privileges may be required if the goal is to spoof an existing secure website, if the hacker creates an entirely new website that appears to have been validated by a trusted CA, elevated privileges aren t necessary. Another side of SSL threats Heartbleed The situation of user trust was complicated even further by the Heartbleed bug, which revealed a different side of SSL vulnerability. Unlike the Apple ios flaw, this bug was found in a popular core software library, OpenSSL, which is used by a large number of websites to implement SSL encryption. Unlike the Apple flaw, the Heartbleed bug has nothing to do with serving up fraudulent Web pages, because it s in the software used to handle the encryption itself. This means if a web server is using the library, it can make anything on that server vulnerable.

As the name implies, the bug affects a portion of the OpenSSL library that involves the heartbeat, which is part of the SSL handshake process. Heartbleed is a fundamental flaw that could expose private data, stored in memory, during SSL communications. This bug is particularly dangerous because even the precious private key used to decrypt data could have been exposed within routine SSL traffic. In addition, usernames, credit card numbers and other sensitive data could have been leaked during this process. And organizations would have no way to determine what data might have been lost, since the memory space where unintended data could be hiding, is recycled within short time frames. One of the reasons Heartbleed received so much global attention is that it went unnoticed for eighteen months, and no one knows what data may have been lost during that period. How Heartbleed Works Client/ Browser Send me this 4 letter word: Fish Fish. Server Malicious user Send me this 500 letter word: Fish Fish. Public Key is 35419845854566. User Dan Brown s Mastercard 5418-2279-3344 Man-in-the-middle attacks Another aspect of the Heartbleed bug is that security holes may have been opened inviting man-in-the-middle attacks (MiTM). The way MiTIM attacks work is that a third party hijacks a data transfer and pretends to be each side of the communication. In the case of Heartbleed, the sender s private keys may have been exposed during the years the flaw went unreported and anyone who obtained the key can now launch a MiTM attack.

Defending against SSL Threats is Challenging The growth of SSL traffic has meant security providers must deal with a growing number of SSL flaws and exploits, and many are promoting their ability to scan SSL traffic for malware and threats. However, some of their approaches either create additional security holes, or impede network performance. Many standard approaches incur problems with SSL security because they lack visibility over the entire Web stream, including hidden UDP data channels, which increasingly carry SSL traffic and are becoming a popular way for cyber criminals to launch attacks. The data streams that use UDP data channels are more difficult to secure because many solutions can t stop data transfers mid-stream. SSL threats piggybacking on TCP traffic through port 443, are easier to detect and block, which is why cyber criminals have switched their focus from TCP to UDP ports carrying SSL traffic. Also, as with the Zeus Trojan, many peer-to-peer programs such as BitTorrent and others, are using SSL traffic to circumvent security solutions, enable anonymous browsing and deliver damaging malware. Mobile devices and SSL Another challenge to SSL security is the expansion of mobile devices in the workplace and elsewhere, including popular bring-your-owndevice (BYOD) programs. Because mobile devices run on many different platforms and browsers, root certificate incompatibility becomes another hurdle. Also, organizations using a security solution that decrypts all SSL traffic as part of its approach, may be in jeopardy of encroaching on the privacy rights of BYOD users on personally-owned mobile devices. There are different approaches to securing SSL traffic Traditional Web security solutions offer different ways to deal with SSL traffic, but some of them leave security holes or create latency. Here are summaries of approaches to SSL security: Approach #1 Ignore SSL Traffic and let it pass by: This approach may have worked when the SSL was new and its security was more reliable, but as recent vulnerabilities and exploits illustrate, organizations can no longer assume that SSL/HTTPS traffic is secure from exploitation. Some traditional security solutions are unable to inspect SSL traffic and consequently it all passes by, opening the door for a variety of threats and potential data loss. Approach #2 Block SSL Traffic: This isn t practical as SSL is increasingly used by organizations in every industry to secure both their inbound and outbound traffic. Its widespread use in industries such as finance, healthcare, government and others, means that blocking it completely creates productivity problems and could interfere with mission-critical processes. In addition, many solutions that block SSL completely do so via proxy settings, which leave organizations vulnerable to port-evasive exploits using SSL on non-standard UDP data channels. Approach #3 Inspect and decrypt all SSL traffic: There are major problems with this approach. The first is that decrypting, inspecting and re-encrypting every data transfer puts excessive strain on network resources. In regulated industries such as finance and healthcare, network availability is critical. Tying up resources for thousands of decrypt, re-encrypt processes throughout the day can create network logjams that negatively impact productivity, regulatory compliance and user satisfaction. This approach can also leave organizations open to man-in-middle attacks. There are disadvantages to each of the approaches above that can expose your network to threats or slow performance. On the next page read how approach #4 protects against SSL threats without jeopardizing network availability.

Approach #4: iboss Selective Decryption at the Gateway Ideally, don t decrypt if you don t have to. Unfortunately, legacy Web security solutions and UTMs don t give you a choice. Only iboss provides granular management of SSL traffic by directory workgroup user, without decrypting or presenting warning messages, which can slow the network and hurt productivity. To do this, iboss leverages patented and patent-pending technologies which extend granular SSL traffic management across the network without decryption, and also gives you the ability to decrypt in situations where inspection or control inside SSL traffic is desired. The iboss approach is your best choice: This approach offers more protection and better network performance than the three extreme approaches being used by legacy Web security solutions, UTMs and NGFWs, namely: Decrypting all SSL, blocking all SSL, ignoring all SSL. Selective decryption enables content-aware SSL management in these critical situations: Across BYOD users where decrypting SSL traffic violates privacy laws. In countries where decrypting SSL is illegal. In highly regulated industries where decrypting SSL is a serious violation. Solutions that scan and decrypt all SSL by pushing certificates may allow exceptions for BYOD or regulated traffic, but users will get a warning message in the browser that they may not understand. If admin solves this problem by disabling SSL inspection, security holes are created. Content-aware granularity ensures that SSL decryption can be restricted for parts of a website or for workgroups, individuals or domains, in accordance with your organization s precise requirements.

Other iboss SSL features include: Exclusive Visibility: iboss technology provides visibility across all 131,070 data channels on your network in cluding hidden streaming UDP ports where SSL threats may hide. Circumvention defense: iboss technology combines scanning inside SSL with application layer scanning across all Web streams, using signatures and heuristics, to block circumvention attempts. Data Loss Protection: iboss content-aware SSL inspection detects threats immediately and restricts access to suspicious SSL traffic. Granular social media controls: iboss content-aware scanning of SSL traffic allows you to create group policies that manage access per page content, so your organization can use social media productively. Google Application Control: iboss accurately identifies each Google appli cation and allows access based on group membership and only to parts of Google Services, for granular, policy-based control. Forensic-Level Reporting: iboss incorporates industry-leading, forensic-style reporting through the iboss Threat and Event Console Reporter, which provides unrivalled insight into the blind spots in SSL traffic. EdgeScan Unique feature for Windows OS: iboss provides advanced SSL scanning at the individual workstation, rather than at the net work gateway to mitigate the risk of MiTM attacks. About iboss Cybersecurity WP/SSL-06/15 iboss Cybersecurity defends today s borderless networks against malware, advanced threats and data exfiltration with innovative Web Security, Mobile Security and FireSphere Advanced APT defense. Unlike legacy technology focused solely on keeping malware out, iboss offers a balanced cybersecurity approach with equal emphasis on prevention, detection and containment to reduce damaging loss from data breaches. Backed by patented, next-generation technology and unparalleled visibility across all inbound/outbound data channels, iboss Smart Defense provides better security weapons to reveal blind spots, detect breaches and minimize the consequences of data exfiltration. Leveraging leading threat protection and unsurpassed usability, iboss is trusted by thousands of organizations and millions of users. Visit www.iboss.com iboss, Inc. (P) 877.742.6832 Sales@iboss.com U.S. HQ 9950 Summers Ridge Rd., Bldg. 160 San Diego, CA 92121 2015 All rights reserved. iboss, Inc. All other trademarks are the property of their respective owners.