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
SSL decryption is not required; App-ID can identify SSL traffic without decryption.
- ✓
The firewall is not seeing the full SSL handshake due to asymmetric routing.
Why this is correct
Asymmetric routing can prevent the firewall from seeing the SSL handshake, causing it to identify the traffic as HTTP.
- ✗
The default interzone rule is blocking the SSL identification packets.
Why it's wrong here
Interzone rules affect forwarding, not App-ID identification.
- ✗
The security policy allows 'web-browsing' before 'ssl' in the rule order.
Why it's wrong here
Rule order affects policy matching, not App-ID 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 — 504 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.