10-28-2020 04:33 PM
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
