←
Back to Blog
Security best practices
3/21/2025
-
XX
Minute Read
How cert pinning and E2EE broke your CASB — and why endpoint is the new cloud control point
Cloud adoption among enterprises accelerated around 10 years ago. During this time, network-based tools emerged as solutions that could protect data as it traveled to the cloud. These solutions, including Security Service Edge (SSE) and Cloud Access Security Brokers (CASB), utilized network-based proxy architectures that could intercept and control traffic. By inspecting data in transit, it ensured that data was controlled according to security policies, effectively preventing exfiltration of confidential data.
However, several developments have undermined network-based approaches. Today’s use of certificate pinning and end-to-end encryption (E2EE) have increasingly put traffic beyond the reach of network-based inspection methods, creating a situation where traffic is blindly allowed to pass or blocked. Endpoint-based approaches, on the other hand, have reemerged as the modern solution to prevent data loss. By analyzing data before it leaves the network, endpoint solutions are able to provide deep visibility into data context, while enabling the business to continue accessing important cloud services.
How network-based tools protected data
Understanding the architecture of network-based security tools reveals their fundamental limitations in today's environment. These tools operate through:
- Traffic routing: network traffic is directed through proxy servers
- SSL/TLS interception: optionally, encrypted traffic is decrypted for inspection
- Content analysis: data is examined against security policies
- Policy enforcement: actions are taken based on predefined policies
- Re-encryption: traffic is re-encrypted before continuing to its destination
This process, while effective for traditional network traffic, faces significant challenges with modern cloud-native applications and zero-trust security models.
Establishing a secure connection
Let's take an example of a commonly used application like Dropbox. When a desktop application like Dropbox connects to its cloud services, it establishes a secure connection through a series of critical steps.
When users open Dropbox, the application initiates communication with Dropbox’s servers by sharing its supported encryption capabilities. The server responds with its security requirements and presents its digital certificate — a form of digital ID card that proves the server is actually Dropbox. The Dropbox application verifies this certificate against trusted authorities to ensure it's connecting to a legitimate Dropbox server. Once verified, the application and server exchange encryption keys, creating a secure tunnel for the data.
However, when network security tools attempt to inspect this traffic, they can disrupt this carefully orchestrated security process, potentially breaking the application's ability to connect securely. Which leads us to the topic of certificate pinning.
Introducing certificate pinning
Certificate authorities could be compromised by a man-in-the-middle (MITM) attack by presenting a fraudulent certificate. To address this vulnerability, certificate pinning was introduced. Certificate pinning adds an extra security layer whereby trust isn’t solely based on the CA. With certificate pinning, a client’s trusted digital certificate is "pinned" or stored within the application. The client only establishes a connection with a server that has the same pre-configured certificate. This security step prevents MITM attacks as the client will only connect to the intended server and not an imposter.
Challenges of certificate pinning with network-based tools
Certificate pinning is an increasingly common practice to authenticate client-server connections. However, this practice comes with a number of drawbacks when combined with network-based security approaches.
Failure to connect to cloud services. Most application traffic is secured via the SSL/TLS protocol, which encrypts traffic to servers. Network tools must decrypt the traffic to inspect it. However, the decryption process involves intercepting and re-signing the traffic, which presents a certificate that is trusted by the device but does not match the exact certificate hard coded into the application and prevents the client from connecting to the server. There is no workaround or upcoming feature for SSE/CASB vendors to address this limitation. It is fundamentally impossible for them to decrypt this traffic. Therefore, it is impossible to inspect this traffic and stop sensitive data from going to the cloud.
Management overhead. To enable clients to connect to cloud services, security and IT teams relying on network-based tools must add the application to an exceptions list. The list of exceptions can quickly grow to dozens or more applications that security and IT teams must continue to add to, remove, and update. These applications include common productivity tools used by organizations such as Adobe Creative Cloud, Cisco Webex Teams, Dropbox, Workday, and more.
Lack of security. Traffic from exempt applications is not monitored. For example, when a sensitive file is uploaded to the Dropbox client, there’s no way for traditional network-based tools to know or stop it.
Establishing a secure connection to chat services
Modern desktop chat applications employ sophisticated security measures to protect critical business communications. Applications like Microsoft Teams and WhatsApp for Business use different approaches to secure messages and files.
Enter End-to-End Encryption (E2EE). When an employee sends a message using the WhatsApp for Business desktop application, the content is encrypted on their device before transmission using the recipient’s public key. Only the recipient with the corresponding private key can decrypt the message. WhatsApp or anyone else can't read the message content; only the intended recipient can decrypt and read it.
Traditional network security tools that perform SSL/TLS inspection face a fundamental limitation with E2EE chat applications. With E2EE, chat application messages are encrypted on the device before SSL/TLS encryption. Even when SSL/TLS inspection decrypts the network traffic, the message content remains encrypted. This process makes network-based DLP and content inspection tools blind to reading or analyzing the message content. Traditional network-based solutions may provide a preconfigured exceptions list of pinned applications including E2EE apps to bypass, but security and IT teams will find it incredibly challenging to keep up with an ever-expanding application ecosystem.
Endpoint is now the ideal, modern cloud control point
Endpoint agents enable security teams to monitor data that is being shared between the client and server, without disrupting the business or compromising security.
Unlike network-based security tools, an endpoint agent can inspect the contents of the data on the device, enabling security teams to understand the data before it is encrypted to send over the network and automatically triggering actions against preconfigured data protection policies. Because inspection is done at the endpoint, there is no need to decrypt the traffic, which would otherwise break a pinned connection. Security protocols via SSL/TLS and E2EE are maintained, allowing encrypted traffic to travel from the client to the server without issue. This eliminates help desk tickets and cumbersome troubleshooting efforts focused on determining why users were unable to complete their job function.
The benefit of an endpoint approach is that traffic from desktop applications to the cloud are inspected and action is taken to stop data exfiltration. Organizations can continue to access the applications they need to conduct business, and there are no list of complex exceptions to maintain.