08-13-2014 09:28 AM
For a long time we've had a rule that grants access to the youtube application (and its sub-applications) as well as the google-video-base application. This rule grants access for people to watch YouTube videos if they are in a certain Active Directory group. We globally allow access to the following URLs, so that YouTube access is controlled by the network signature ("application") alone:
Google must have changed something recently because now a ton of people that are permitted to watch YouTube videos have been calling our helpdesk complaining that videos are not working. I've troubleshot this and found that it always works for people in the group if they viewing YouTube unencrypted (HTTP). If they are using encrypted (HTTPS) site, including if they are signed into a Google account, the videos do not work. I was able to get this to work on HTTPS for some people if I allowed the URL "*.c.docs.google.com" in their URL filtering profile. But other people still have trouble despite this because in such cases there is no evidence that their computer is trying to get to "*.docs.google.com". In such cases, the firewall logs report nothing denied or blocked at all in the traffic, threat, and url-filtering logs.
Does anyone have a suggestion?
08-18-2014 09:42 AM
I am exhibiting the same situation where specific users who are allowed access to youtube are getting blocked (whereas the rest are denied access). Logs show Youtube on port 80 allowed through the correct policy, but as soon as it hits port 443, it gets blocked by the lower deny rule assigned to the rest. One change that seemed to work was switching from service 'application-default', to service 'any', which is not ideal.
08-18-2014 10:50 AM
You should track the URL Filtering logs for the blocks.
Sometimes there can be HTTP redirects, if that's the case, it may not be logged to the URL Filtering logs.
If that's the case and you can't find it, you can try going to the URL Filtering profile and uncheck the option to "Log container page only".
You should also decide to try allowing:
*.google.com
google.com
... but this can result in allowing more access than intended. Hunting the URL's through the URL Filtering logs would be the best strategy if you wouldn't want to allow too much access to google.com.
Once you're done troubleshooting, it is recommended that you check the "Log container page only" option under the URL Filtering profile to avoid excessive logging.
Additionally, if the connection is HTTPS, and you have *no SSL Proxy* decryption implemented, the filtering will happen by a wildcard match to the CN presented on the SSL certificate. If that's the case, check out How to Block a Specific HTTPS Site with URL Filtering
Mariano.
08-18-2014 12:27 PM
My issue turned out to be completed unrelated to the Palo Alto Networks firewall. What follows is completely unrelated to Palo Alto Networks firewall, but might help someone else troubleshooting a similar issue.
The people in my organization that were unable to access YouTube videos that should have been able to were using Internet Explorer 9 on Windows 7 computers that were FIPS-compliance-enabled (the setting "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" was set to "Enabled"). When you view a YouTube video, the browser calls out to various hosts on the "googlevideo.com" domain (e.g. r5---sn-hp576m7r.googlevideo.com, r14---sn-hp576m7z.googlevideo.com, r5---sn-hp576m7d.googlevideo.com, etc.). I am not sure if the videos are hosted there or it is just some sort of check that is done or what, but it seems critical to the operation of the YouTube videos themselves.
If you check the Qualys SSL Labs SSL Test for any of these sites, you will see that they only support the cipher suites TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA. The former is not available on Windows 7. The latter is, but is not FIPS 140-2 compliant and is therefore disabled in Schannel on FIPS-compliance-enabled Windows PCs. Internet Explorer uses Schannel to handle TLS.
Additionally, Google seems to be forcing HTTPS on YouTube.
Basically all of these things combined means that one cannot access YouTube videos using Internet Explorer on Windows 7 computers where FIPS-compliance mode is enabled. The videos work in Google Chrome on such computers, but only because Google Chrome uses its own library for TLS and does not pretend to be FIPS 140-2 compliant at all. I don't believe they would work in Mozilla Firefox if Firefox itself is in FIPS-compliance mode (a separate process beyond the Windows setting), because it doesn't look like TLS_RSA_WITH_AES_128_GCM_SHA256 is implemented in NSS at this time and TLS_RSA_WITH_RC4_128_SHA is not FIPS-compliant.
TLS_RSA_WITH_AES_128_GCM_SHA256 is implemented in Schannel in Windows 8.1 if KB2919355 is installed, so YouTube would work fine on such Windows 8.1 computers even if FIPS-compliance mode is enabled.
So basically, here is my path forward:
The true solution would be for Google to either allow us to use YouTube on plain HTTP or to support at least one FIPS 140-2 compliant cipher suite that is available on Windows 7, but I hardly expect them to listen to little ol' me. In fact, I've posted on the YouTube Help Forum, which is all that Google seems to have for YouTube support and have gotten no response thus far. Here is my post there: https://productforums.google.com/forum/#!searchin/youtube/fips/youtube/ia2WyQBnM30/c7Dj-79iM_MJ.
The fact that Google only supports those two cipher suites on these googlevideo.com hosts is odd, as www.youtube.com supports 27 cipher suites, many of which are available in Windows 7 even in FIPS-compliance mode. The only thing I can think of it is some sort of BEAST attack mitigation, as TLS_RSA_WITH_RC4_128_SHA is not vulnerable to BEAST nor is any TLS protocol 1.1 or higher and TLS_RSA_WITH_AES_128_GCM_SHA256 is only available in TLS 1.2. But this server-side method of mitigation is no longer recommended as BEAST has been mitigated client-side in all the major browsers at this point in time, TLS_RSA_WITH_RC4_128_SHA is known to be weak, and TLS 1.2 is not widely available on all devices (or at least not widely enabled by default).
08-18-2014 02:46 PM
Based on what you describe, you are decrypting packets, otherwise a change in service from 'application-default' to service 'any' wouldn't resolve the issue. In your case it can be that the application you selected doesn't have 443 as an application default port. An alternative solution is leaving service as 'application-default' but adding ssl to the list of allowed applications on your Security Policy.
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!
