Caveats for HTTP Header Insertion for GDrive / Google Apps

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Caveats for HTTP Header Insertion for GDrive / Google Apps

L1 Bithead

As of the time of this writing (May 2020), there are some caveats / required steps for HTTP header insertion into GDrive applications that are not clearly documented. The purpose of this post is to close that gap until documentation is amended to correct this (Documentation has now been updated - Oct 2020 update)

 

1. Decryption

All google apps are encrypted (shocking I know) so you do need to institute SSL Decryption. I created what might be an overzealous decryption policy but it got the job done. Decryted the following categories:

business-and-economy, computer-and-internet-info, content-delivery-networks (this CDN one was a surprise but needed), intenet-communications-and-telephony, low-risk, online-storage-and-backup, search-engines, web-based-email

Plus a custom URL category for GDrive Cached URLs - see this KB article: Identifying and Blocking Google Drive when Using Chrome-cached Session

2. HTTP/2 -> HTTP/1.1

Google Apps also use HTTP/2 instead of HTTP/1.1 for performance improvements. However it is not possible at this time for our technology to insert headers into HTTP/2 traffic. When configuring the SSL Forward proxy decryption, check the flag for stripping ALPN in the decryption profile you apply to this traffic. When you strip the ALPN value, this causes traffic to default back to HTTP/1.1, where we can insert headers.

From a user's perspective this shouldn't change the app usage, it will just cause a performance reduction (YMMV) from a network perspective.

At this point, some apps, like Gmail, will have the headers properly insert, but you will see that others still continue with the default (non-blocked) behavior, such as GDrive

3. To close the final gap, you will have to create a rule at the top of the security policy set that blocks the QUIC App-id. This is because Google uses their proprietary QUIC protocol to deliver GDrive and some other apps, instead of the standard HTTP over TLS, in which we cannot decrypt and insert headers. If you block the QUIC protocol, it will default back to HTTP/2 over TLS, then the decryption with ALPN stripped will further turn it into HTTP/1.1 and finally you will have header insertion working.

For the header insertion, I also included the following domains in the HTTP Header Insertion config of the URL filtering profile (may be more coverage than needed but did this for an eval so was less concerned with tuning that getting the W):

*.google.com

*.gmail.com

*.googleusercontent.com

*.drive.google.com

*.gstatic.com

1 REPLY 1

Community Team Member

Thank you for the heads up !

LIVEcommunity team member, CISSP
Cheers,
Kiwi
Please help out other users and “Accept as Solution” if a post helps solve your problem !

Read more about how and why to accept solutions.
  • 4794 Views
  • 1 replies
  • 5 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!