What Is SSL Web Inspection and Where Should It Occur? (Part 3) 

In parts one and two of this blog series, I provided an overview of SSL web inspection, and dove deeper into how SSL inspection solutions work and metrics that can be put in place to measure effectiveness. In this third and final post of the blog series, I will discuss the benefits and downsides of SSL inspection, and how to put a plan in place for your organization.

Benefits of SSL Inspection

The benefits to an organization could be limitless and somewhat interpretive based on an organization’s needs. Most companies start with the ‘need’ or business case of SSL inspection and work backwards on how to accomplish this. Here we will focus on some of the more popular needs:

• More advanced URL categorization and application control
• Malware/Virus analysis (i.e. sandboxing, AV scanning, etc.)
• DLP
• Advanced network monitoring and troubleshooting
• Better visibility into cloud applications
• Send traffic to other tools
• Better efficacy of existing security solutions

All-in-one devices can do most of the above-listed functions but require sizing to be appropriate if SSL inspection is done on the same device. Inevitably organizations will have to size for not only how much SSL inspection is done but also what functions it will do and how much load those functions can be expected to handle. The device may be the only place where SSL inspection is needed so the cost of oversizing may be fine. However, most organizations want the benefit of using other tools to see unencrypted traffic, and all-in-one devices typically don’t function that way. Some all-in-one devices can send decrypted traffic to a mirror port, but that functionality is rudimentary today.

Purpose-built devices must be able to handle the functions listed within the ‘How it Works’ section but rarely provide any other functions, so sizing is based on SSL inspection only. The other devices inspecting unencrypted traffic are sized for the functions they will provide, and the load those functions are expected to handle. Again, many organizations will want to use other tools (future or existing) to gain visibility into unencrypted traffic. The purpose-built solutions have the benefit of ‘decrypt once and send to many’ (e.g. unencrypted SSL traffic is simultaneously sent to a web proxy and a network IDS).

Cloud providers offer many of these functions as well, but with some providers the data remains within their environment for logging and reporting. However, this can create a disconnect when piecing information together for a holistic view of security.

Downside of SSL Inspection

There are many issues with SSL inspection, and some are as dynamic as browser updates, but most can be avoided with proper planning. A partial list of the common issues are mentioned below.

• Some applications do not function with SSL inspection
  • Do not follow RFC standards
  • Unsupported ciphers
  • Client certificate authentication
  • Proprietary protocol support
  • The application is hard coded to accept a specific certificate or can’t be configured to trust another CA
  • Certificate checks after the initial handshake is complete
• Certificate errors cause inspection to fail
  • SHA1 use
  • Poor PKI implementation
  • Misuse of certificate fields (i.e. SNI or SAN data)
  • Broken certificate chaining
• Exposing user’s personal information
  • Banking
  • Healthcare
• Violating laws in some countries
• Other privacy concerns towards anonymity based sites
  • Government whistle blowing
  • Sexual harassment
• The SSL inspection device can make the connection less secure
  • Older versions of TLS can be used
  • Older cipher suites on the devices can negotiate a less secure connection that is susceptible to MITM attacks
  • Server certificate validation is either not done or does limited checks
• Browser updates that change behavior
  • Enforcing SAN names in certificates
  • Enable TLS 1.3 negotiations
  • Certificate checking and pinning

Planning, Sizing and Conclusion

The first place an organization should start is with their security policies that have been put in place by a governing board. Governance is not the focus here, but the governing board should provide direction on what the organization is inspecting (what is interesting) for and informing the users of such activity.

The next step is to review the logical architecture and physical layout of the network in its current state and, if possible, future state. The primary goals are to identify how traffic flows within the network and what type of traffic is on the network. This information, in conjunction with requirements of interesting traffic/data that is defined by the governing body, will help determine where traffic will need to be inspected. Most organizations start with inspecting inbound and outbound SSL traffic at the network perimeter. A common location is just inside the perimeter firewall, and before any proxy solution. This will put the SSL solution close to the user so the packet is not modified, but also in a place to capture as much traffic leaving the environment as possible. Once the location is determined the amount of SSL traffic that is in scope needs to be determined.

Determining interesting SSL traffic requires equipment that can categorize SSL traffic based on application and/or URL. This was discussed in the earlier section of “How it Works.” Organizations may already have equipment that can help with this. If not, an information security partner can help determine what is needed and assist. It is recommended that organizations involve their information security partner early in the process to help with real world expectations of traffic behavior, and narrow the selection process of vendors that can accomplish the overall objective. The equipment should be placed off a span/TAP port that receives bi-directional traffic from the logical placement determined earlier. It is important to note that you probably won’t be able to decrypt traffic at this point since the equipment is in a passive state.

Once you have high-level visibility into what type of traffic is being seen as SSL, and the approximate amount; the organization will need to work internally to determine what is in scope. This is completely subjective to the governing policies in place, what an organization is protecting against, and the risks associated with traffic that is and is not in scope. An information security partner can provide suggestions and guidance, but ultimately the decisions fall to each organization. Organizations also need to discuss what other benefits they will get from decrypting the traffic in scope and the value of those benefits. This process will provide the amount of interesting traffic that will be used for sizing later.

The other factors that should be discussed during this process are how much projected SSL growth an organization can expect, any future plans for a remote workforce, and the direction of the business regarding SaaS applications. If SaaS applications are being adopted and intellectual property is considered interesting traffic, an organization may consider a Cloud Access Security Broker (CASB) solution as well.

At this point an organization should know how much SSL traffic is in scope, what they want to inspect for, where the solution will be placed, and the peripheral benefits of decrypting the traffic. This ultimately determines if SSL inspection should be done via an all-in-one or purpose-built solution.