Palo Alto App-ID Overview:

App-ID

Identifies applications in traffic and observes them by the firewall to understand their behaviour and set policies to control them.

1) App-ID Signature Matching

Identifies applications by matching traffic to application signatures.

Signatures are based on application behaviour, not port or protocol.

2) Protocol Decoder Identification

For protocols like SSL and SSH, check the Decryption policy.

3) Behavioural heuristics

Attempts to identify behavioural patterns consistent with known applications.

E.g.: Identifying BitTorrent traffic by identifying P2P traffic.

4) Unknown Traffic

Traffic not identified by App-ID is handled by the security policy.

How Unknown Files Are Handled

• Traffic enters the firewall.

• If App-ID / signatures cannot identify the file, it may be treated as unknown.

• If the WildFire Analysis profile is enabled, the firewall sends the file to the WildFire sandbox.

• The sandbox analyzes the file behavior.

Typical analysis time: about 5–15 minutes

After WildFire Analysis

If the file is malicious:

• A new signature is created.

• The signature is distributed through WildFire / Threat updates.

Protection methods updated:

*Antivirus signatures

• Anti-Spyware signatures

• URL / DNS protection (sometimes)

You need one of these licenses:

• WildFire subscription

• Threat Prevention subscription

Without a license:

• The firewall cannot submit files to WildFire.

• It will not receive new signatures.
• WildFire analysis = 5–15 minutes
• Signature released after analysis
• License required (WildFire / Threat Prevention)

Another Important Point

The diagram you sent shows the App-ID identification flow:

Traffic → Signature → Protocol decoder → Behavioral heuristics → Unknown

If still unknown and a file is present → WildFire analysis can be triggered.

Correct Flow:

Unknown File ↓ WildFire Submission ↓ Sandbox Analysis (5–15 min) ↓ Malicious Verdict ↓ New Signature Created ↓ Threat/WildFire Update Released ↓ Firewall Blocks Future Attempts

SSL Traffic Identification Without Decryption (Using SNI):

Firewalls can sometimes identify SSL traffic without full decryption using Server Name Indication (SNI).

1) Client Sends TLS Client Hello:

• When a client connects to an HTTPS server, it sends a TLS ClientHello packet.

Inside this packet, there is an extension called:

• Server Name Indication (SNI)

Example:

Client → Firewall → Server TLS ClientHello SNI = www.youtube.com

2) Firewall Reads the SNI Field:

• The firewall does not need to decrypt the traffic.

• It can inspect the SNI field in plaintext.

The firewall extracts:

• Domain name

• Hostname

Example extracted value: www.facebook.com

3) App-ID Identification:

Using SNI, the firewall can identify applications such as:

• Facebook

• Youtube

• Google Drive

*office365

Even though traffic is encrypted.

4) URL Category Matching:

The hostname from SNI is also used for:

• URL filtering

• DNS security

• Security policy matching

Example :

SNI = netflix.com

URL Category = Streaming Media

5) Security Policy Enforcement

Firewall can apply policies based on:

• Application
• URL category
• Domain name

Example rule:

Application: YouTube Action: block

Important Limitations

SNI works only if the client sends it.

Situations where it fails:

• Some malware hides SNI
• TLS 1.3 encrypted SNI (ESNI / ECH)
• Custom applications
• Non-HTTP TLS apps

In those cases, the firewall may see:

• ssl
• unknown-tcp

Quick Identification Flow:

Encrypted Traffic ↓ TLS ClientHello ↓ Read the SNI field ↓ App-ID mapping ↓ Security policy applied

Key Interview Point:

SNI allows application and domain identification without SSL decryption.

I can also show the complete encrypted traffic inspection flow (ClientHello → SNI → Certificate → App-ID), which is another common PCNSE interview topic.