Why HTTPS Traffic Is Identified as web-browsing: Asymmetric Routing Without SSL Decryption
During a security audit, it is discovered that some HTTP traffic is being incorrectly identified as 'web-browsing' instead of 'ssl' even though the traffic uses HTTPS. The firewall is positioned as a transparent bridge and no SSL decryption is configured. What is the most likely cause?
Quick Answer
The answer is asymmetric routing without SSL decryption, which prevents the firewall from seeing the full TLS handshake. When a Palo Alto Networks firewall operates as a transparent bridge and lacks SSL decryption, it relies on the Server Name Indication (SNI) field and certificate exchange during the handshake to classify HTTPS traffic as 'ssl'. Asymmetric routing causes the firewall to see only one direction of the TCP handshake—such as the SYN or SYN-ACK—so it never observes the complete TLS negotiation. Without that full handshake, App-ID cannot extract the necessary signatures like TLS version or cipher suites, and it falls back to classifying the traffic as 'web-browsing' based solely on port 443. On the PCNSE exam, this tests your understanding of how App-ID behaves when decryption is off and routing is asymmetric; a common trap is assuming port-based classification is sufficient. Memory tip: no handshake, no SSL—asymmetric routing breaks the TLS conversation.
⚠ Common exam trap
A common mix-up: candidates assume SSL decryption is mandatory for SSL identification, but the firewall can identify HTTPS without decryption by inspecting the TLS handshake; the real issue is that asymmetric routing prevents the firewall from seeing the complete handshake, causing App-ID to fall back to port-based classification.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The firewall is not seeing the full SSL handshake due to asymmetric routing.
When a firewall operates as a transparent bridge without SSL decryption, it relies on the Server Name Indication (SNI) field or the certificate exchange during the TLS handshake to identify HTTPS traffic as 'ssl'. Asymmetric routing causes the firewall to see only one direction of the TCP handshake (e.g., only the SYN or only the SYN-ACK), preventing it from observing the full TLS handshake. Without the complete handshake, App-ID cannot extract the necessary signatures (e.g., TLS version, cipher suites, certificate details) and falls back to classifying the traffic as 'web-browsing' based on port 443.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
SSL decryption must be enabled for the firewall to correctly identify SSL traffic.
Why it's wrong here
Decryption is not required for App-ID to classify TLS; the firewall reads the ClientHello SNI and certificate without decrypting. Enabling decryption would expose payloads, but the stem states none is configured, so it cannot explain the misclassification. Decryption is chosen when you need to inspect encrypted application content, not merely identify the protocol.
- ✓
The firewall is not seeing the full SSL handshake due to asymmetric routing.
Why this is correct
A transparent bridge without decryption must infer the application from the TLS handshake. With asymmetric routing, return traffic bypasses the firewall, so it never observes the full handshake and falls back to classifying the flow as web-browsing on port 443 instead of ssl.
- ✗
The default interzone rule is blocking the SSL identification packets.
Why it's wrong here
The default interzone rule permits or denies traffic; it does not strip App-ID identification packets. HTTPS without decryption is identified as ssl through certificate and TLS handshake inspection. This option would be correct if a security policy were explicitly blocking the application identification update traffic.
- ✗
The security policy allows 'web-browsing' before 'ssl' in the rule order.
Why it's wrong here
Security policy rules control whether traffic is permitted or denied; they do not determine App-ID classification. The application is identified before policy lookup, so rule order cannot cause HTTPS to be labelled web-browsing. Rule ordering matters when overlapping permit rules must be sequenced for access control, not for application identification.
Visual reference
Quick reference
Asymmetric Encryption Algorithm Comparison
| Algorithm | Key Exchange | Signatures | Equivalent Security Key | Notes |
|---|---|---|---|---|
| RSA-3072 | Yes | Yes | 128-bit | Widely deployed; slow for bulk data |
| ECDSA P-256 | No | Yes | 128-bit | Fast signatures; standard TLS certs |
| ECDH / ECDHE | Yes | No | 128-bit | Perfect forward secrecy in TLS 1.3 |
| DH / DHE | Yes | No | 128-bit (3072-bit key) | Replaced by ECDHE in modern TLS |
| Ed25519 | No | Yes | ~128-bit | SSH keys, modern PKI |
Go deeper
Related to this question
About these practice questions
Courseiva writes every PCNSE question from scratch — 319 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on PCNSE
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which THREE of the following can cause App-ID to incorrectly identify traffic?
hard- A.Multiple security rules are configured for the same traffic.
- ✓ B.Asymmetric routing causes the firewall to see only one direction of traffic.
- ✓ C.SSL decryption is not enabled for the traffic.
- ✓ D.IP fragmentation occurs before the firewall.
- E.Traffic is forwarded through an HTTP proxy.
Why B: Asymmetric routing causes App-ID to see only one direction of traffic (e.g., SYN but no SYN-ACK). App-ID relies on bidirectional flow inspection to identify applications; without seeing both directions, the firewall cannot complete the application signature match or protocol handshake, leading to incorrect or failed identification.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCNSE practice question is part of Courseiva's free Palo Alto Networks certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCNSE exam.