Hey everyone! 👋 I've been implementing Netskope for our mid-sized tech team over the past few months, and we're finally getting into the fine-tuning phase. We want to enable SSL decryption across the board for better threat visibility, but the network team is (understandably) concerned about latency.
From my testing so far, the impact isn't zero, but it's also not a blanket "everything gets slower." It really depends on your architecture. Here's what I've observed:
**Our setup:**
- Using inline CASB with a forward proxy
- Traffic steering via PAC files
- A mix of cloud and private instance gateways
**The latency factors I've measured:**
* **Initial Handshake:** This is where you'll see the most consistent hit. The MITM proxy has to establish two TLS connections (client→proxy, proxy→server). In our tests, this adds **80-150ms** to the initial connection, depending on the destination server's location and response time.
* **Throughput for Large Files:** Once the connection is established, the impact on download/upload speeds for large files is minimal—usually less than 5% overhead. The crypto is modern and hardware-accelerated.
* **"Chatty" Applications:** This is the sneaky one. Apps that open many simultaneous, short-lived connections (think some SaaS dashboards or API-heavy tools) can feel sluggish because each new connection incurs that handshake penalty.
**A quick test you can run:**
If you're doing a PoC, don't just run a speed test. Simulate real user activity. I wrote a simple Python script to mimic browsing behavior and log timing.
```python
import requests
import time
urls = ["https://example.com", "https://github.com"] # Add your critical SaaS apps
def test_latency(url_list):
for url in url_list:
start = time.perf_counter()
# First request simulates initial page load
resp = requests.get(url)
initial_load = time.perf_counter() - start
# Maybe a secondary resource
start = time.perf_counter()
requests.get(url + "/favicon.ico")
secondary_load = time.perf_counter() - start
print(f"{url}: Initial={initial_load:.3f}s, Secondary={secondary_load:.3f}s")
# Run this with decryption ON and OFF for the same target list.
```
**My advice so far:**
* **Exclusions are your friend.** We exempted banking, healthcare, and certain public sector sites where decryption is a legal no-go. This also helps with latency for those specific flows.
* **Gateway placement is critical.** If your traffic has to take a long detour to hit the Netskope POP, *that* will add far more latency than the decryption itself. Use the tools to find the optimal gateway.
* **Monitor with Real User Monitoring (RUM).** The Netskope dashboard shows you latency metrics—use them! Look for outliers.
I'm curious—what have others seen? Are you decrypting everything, or using a targeted policy? Have you found certain application categories that are particularly sensitive to this?
Clean code is not an option, it's a sanity measure.
That initial handshake hit is interesting. Have you noticed if it's worse for certain cloud apps, like ones that make a ton of new connections? I'm thinking about tools like Figma or Asana that might feel chunky if every tiny request gets that 80ms penalty upfront.
Also, curious if you've measured any impact on email clients with constant background sync. That's a big worry for my team.
You've identified the critical scenario, but the magnitude depends heavily on the proxy's session resumption capabilities and the client's behavior. Modern web apps using HTTP/2 or multiplexed connections largely mitigate this, as the initial handshake cost is amortized. The real pain point is legacy or poorly optimized applications that open a new TLS socket for every single resource - that's where your 80ms penalty compounds.
Regarding email clients, the impact is often negligible for persistent IMAP/Exchange connections, but problematic for modern webmail interfaces (like OWA or Gmail's interface) that use aggressive polling. The constant new connections for "unread count" checks or real-time notifications can introduce a perceivable lag. The fix is usually tuning the proxy's idle timeout to be more aggressive than the client's polling interval, forcing it to resume sessions instead of negotiating new ones.
Have your network team run a packet capture during a Figma session. You'll see if it's a true "new connection per request" pattern or if they're leveraging existing tunnels. That data is more valuable than generalized latency tests.
Trust but verify