ra2 studio - Fotolia
Not every technology supports every organizational goal perfectly. That might sound astoundingly obvious, but it's important to call out because, under the right circumstances, the customizations we make to technology to accommodate specific usage and enterprise goals can translate into potential risk areas in the wrong circumstances.
To use an analogy from our daily lives, consider a kitchen remodel. Accomplishing a task like updating your kitchen means fundamentally altering the design and implementation of what you have now: new countertops, new cabinetry, new flooring and maybe even new appliances. As anyone who has ever done a large renovation knows, changes you make have the potential to introduce new problems or uncover issues you didn't anticipate. For example, you may discover that a slope in the floor causes your new refrigerator to leak, or that there is out-of-code electrical wiring behind the walls.
The same principles are true in the technology world. There are situations where we need to adapt technology to support our organizational goals. And, just like when you remodel a kitchen, there are times when the adaptations lead to additional complexity and issues. HTTPS inspection is one of those areas that is particularly important.
What is HTTPS inspection?
Transport Layer Security (TLS) -- the successor to Secure Sockets Layer (SSL) -- is designed to provide an encrypted channel between two hosts. It has measures built into it to help both parties know if someone is trying to alter, snoop, interfere with, tamper with or otherwise gain access to the communications.
Sometimes, though, the default use case -- such as host A wanting to privately communicate with host B -- doesn't directly support the requirements our organization might have. For example, an organization may want to scan data coming into its environments for malware, parse application traffic for known attack signatures or scan outbound data for data exfiltration. Doing this on an encrypted channel is difficult.
This is where HTTPS inspection comes in. HTTP inspection refers to a situation in which an organization wishes to deliberately introduce a man in the middle (MITM) to a TLS exchange. In other words, it wants to deliberately interrupt the secure communication pathway between two hosts, which typically acts as a transparent proxy to accomplish this.
With HTTPS inspection, there are two TLS connections instead of one between the client and server: one TLS session between the originator and the MITM, and another one between the MITM and the host on the back end. The proxy contains a server certificate and private key used to negotiate a secure session with clients and, on the back end, has a client TLS implementation that handles communication with the host being proxied.
HTTPS inspection is a frequently used strategy for implementation of cloud-specific security tools. For example, many SaaS-focused security products are built around a proxying model. They might do this to encrypt data elements in between a client and a SaaS, to track user activity within a SaaS application, to monitor events or for any number of other purposes. Keep in mind that, in a SaaS situation, everything below layer 7 is a black box from a customer point of view. As such, hooks into the underlying application to implement these security measures are hard to come by.
Risks and implications
US-CERT was recently alerted to the fact that a proxying scenario can also introduce security issues. Alert TA17-075A, issued in March 2017, outlines a number of potential issues that can occur as a result of this technique. The US-CERT guidance draws heavily on a research paper, "The Security Impact of HTTPS Interception," which outlines how issues in implementation can lead to a weakening of the security provided by the TLS protocol because of the transparent man in the middle.
For example, consider a situation where a warning would otherwise be raised during a TLS session negotiation -- such as in the case of certificate expiry, a mismatched name or another issue. A browser might actively warn the user about this situation, and let the user know that something worthy of their attention is transpiring. But, because the proxy has its own client-side communication with the remote host, and there's no direct way to pass along that warning to the user, those warnings might not occur.
Likewise, it might be configured in a fashion the end user finds undesirable -- like, for example, trusting certificates that the user might now want, failing to check certificate revocation status and support of legacy protocol versions, or weak cipher suites.
Because of this, it is important that organizations understand where and how this approach is being used so that they can take steps to validate the implementation, move to alternative strategies or migrate to alternative controls that don't rely on proxying in the first place. But how can an organization do this?
One strategy is to begin with a systematic analysis of where in the organization HTTPS inspection is employed. Ideally, the organization will have ready access to places where HTTPS inspection is used, can initiate a systematic examination of the places where they employ this technique, ask targeted questions and conduct remediation per the CERT guidance. That said, sometimes records are spotty for control deployments, so some additional creativity may be required.
A useful starting point is the X.509v3 certificates required for a proxy-type approach to operate. Keep in mind that, for the session to be trusted, the end-user browser needs to be able to trust the server certificate on the other end of the TLS session -- in this case, the proxy. Since the server side of the session authentication process requires a certificate to succeed, an internal or external certificate authority will have generated that certificate -- unless a business unit is actively trying to operate under the radar.
Given the potential seriousness of this issue, it is worth keeping it in the back of your mind as you review and examine new deployments of controls or applications, and as you evaluate applications, controls and other technologies that you might consider bringing in house to meet security requirements. If you already have HTTPS inspection in play -- or if you find you absolutely need that functionality -- additional rigor brought to bear on the examination of these implementations is time well-spent.
Read more about how interception threatens TLS security
Find out why HTTPS interception tools weaken security
Learn about the challenges of migrating from HTTP to HTTPS