GZIP File - Google Translate

[Hithead]

Hi,

some users reported they are unable to use Google-Translate any more. I saw in the logs, Clients are trying to download GZIP files with the app google-translate-auto and google-translate-manual:

I'm sure, the users were able to use Google-Translate in past. So the problem is since recently.

[scanlab.rgr]

Hi,

we see also many GZIP (f.txt) download attempts with the app web-browsing.

When we block this download Google Instant and Google Maps does not work anymore.

This behavior started last week.

Our Data Filtering protocols are flooded with such entries.

Does anyone also see such a behavior?

Best regards,

Rainer Grothues

[SDorsey]

I'm not a web dev guy.. at all..

But I wonder if they are using HTML5 to get the content to you in compressed format (gzip) then using the power of HTML5 to uncompress it within the browser. It would make their service faster and take less bandwidth.

[SDorsey]

Did you just recently enable SSL decryption? I just tested it and it does not ID any of the traffic as gzip until you decrypt it as Google forces SSL for Google Maps.

[Hithead]

SSL decryption was always on. also for google...

[SDorsey]

It appears my assumption was correct. Google Maps uses gzip compression.

https://google-developers.appspot.com/coordinate/v1/performance#gzip

[Hithead]

but since when? And we talking about google translate (ok, maybe google earth is also effected).

I think, it happens after a content update.

[scanlab.rgr]

Sorry Hithead I brought Google Maps into play with my post.

I made the test also with Google Translate and saw the same behavior as you.

Maybe a little change on the ssl decoder?

[Hithead]

its ok. seems the two problems (apps) have the same root cause.

if we could solve both, google translate and earth, would be nice.

I hope PAN can modify the google apps to let the gzip file passed.

[scanlab.rgr]

You could modify your file blocking policy to allow gzip.

After that all works fine but only if you chose the action allow or forward. Continue does not work.

Nevertheless I would like to know what happened.

[Hithead]

I know this workaround. but the problem is, I cannot select google-translate as application. Don't want to allow gzip with all applications...

[SDorsey]

Create a new ACL line which matches on Google Maps and Google Translate. Create a new File Blocking profile for that rule which allows GZIP.

This will allow you to let GZIP work for these apps but the rest of the traffic will match on your previous rules.

[Hithead]

thank you for your comments guys, but I know this kind of workarounds.

I like to know, if PAN is responsible for this change or Google? And regardless if PAN is able to modify the apps and include gzip as 'necessary'.

[SDorsey]

That is hard to answer depending on many variables.

For example, maybe Google was using TLS1.2 but your PAN was not yet at the version which added 1.2 support so it wasn't decrypting that specific traffic.

Or maybe Google just added GZIP compression to their public services. Or maybe a PAN content update allowed it to better identify GZIP compression within Google apps.

PAN has supported GZIP compression identification for quite a bit though. It even uncompresses and scans GZIP encoded traffic essentially (IPS Scanning of Compressed Files)

As for PAN adding gzip as necessary to the App-ID for the Google Apps, are you just looking for the firewall to tell you that you also need to allow GZIP? Because if you have an explicit deny, I do not believe it auto-allows other needed apps. I think it only does this if you lack an explicit Deny.

But you should always have an explicit deny.