youtube

[santonic]

hi!

digging through the logs of our PA-2020 showed that at some point after Nov 3rd it was not able to recognize youtube as an application any more. since we upgraded from 4.0.7 to 4.1.0 a few days later, I was wondering if you have any idea what might be the cause of this behavior since all other applications seem to be recognized correctly? broken application signatures?

BR, Andrej

[DavePalo]

Hi Andrej,

What version of apps & threats are you running?  I'm on 278-1187 (running on 4.1.0) and I still seem to be getting hits for youtube-base

Regards,

Dave

[santonic]

hi!

I'd say we are running the latest available signatures

Application version 278-1187

Threat version 278-1187

Antivirus version 618-840

URL Filtering version 3745

BR, Andrej

[jnguyen]

I would assume if the application does not show up as youtube it is either detected as web-browsing or ssl. Are you blocking your users from access to youtube and now it is allow access since the application is not detected?

[santonic]

hi!

since PA-2050 is deployed in TAP mode, we are actually only monitoring internet traffic. you are indeed correct about application identification: in the URL filtering log access to www.youtube.com/watch?.... is always identified as web-browsing.

BR, Andrej

[jnguyen]

This should be expected behavior. the application in the url logs will be web-browsing. if you go to the traffic logs do you see youtube-base?

[jnguyen]

I just check on another device and you are correct it can be vary on the application for url filtering logs. i was testing on a lab unit but only saw web-browsing.

if you can log a case online we can have our content team look into this.

[santonic]

hi!

it turned out that changing the action from "block" to "alert" in the URL filtering profile completely changed the device's ability to detect Youtube. if the option "alert" is used both our PA-2020 and PA-2050 deployed in TAP mode are able to correctly identify Youtube traffic.

br, Andrej

[bpappas]

@santonic:

the behavior that you describe is expected. Here's a synopsis of the two scenarios you describe:

URL action == block

1. three way handshake

2. first packet after the three-way handshake allows the device to identify application web-browsing

3. packet passed to URL filtering for decision

4. block decision causes session termination. no further identification work required. we will never identify as a child application of web-browsing

URL action == alert|allow

1. three way handshake

2. first packet after the three-way handshake allows the device to identify application web-browsing

3. packet passed to URL filtering for decision

4. alert|allow decision is made

5. packets are inspected to determine if application is a child app of web-browsing (such as you-tube)

[santonic]

Makes sense, thanx for the explanation.