5G Core Traffic Analysis with Wireshark

5G Core networks rely heavily on IP-based protocols, which means they face many of the same security and troubleshooting challenges found in traditional IP networks. For telecom engineers, Wireshark is useful not only for troubleshooting but also for understanding protocol behavior and identifying unusual traffic patterns.

When 5G Core control-plane traffic is protected with TLS, analyzing the packets becomes more challenging. Instead of simply reading HTTP/2 messages in a trace, engineers need to understand how the Network Functions (NFs) communicate, how TLS is established, and how the relevant keys are made available in an authorized analysis environment.

---

Why Wireshark Matters in 5G Core Networks​

5G Core uses a Service-Based Architecture (SBA), where Network Functions communicate through IP-based interfaces and service-based APIs.
This creates a different troubleshooting workflow compared with older signaling environments.

A typical analysis may require you to:

• Capture traffic between two Network Functions.
• Identify the relevant HTTP/2 connections.
• Inspect TCP behavior and connection establishment.
• Analyze TLS negotiation.
• Identify the communicating NFs.
• Examine HTTP/2 streams and requests when decryption is available.
• Compare the observed behavior with the expected 3GPP protocol flow.
• Look for unexpected connections, malformed messages, or unusual traffic patterns.

The important point is that a packet capture is only useful when you can interpret what the protocol is actually doing.

---

Why Encrypted 5G Traffic Is Harder to Analyze​

In older telecom signaling environments, engineers could often inspect signaling messages directly in a trace. With TLS-protected 5G service-based communication, the application payload may not be readable from a normal packet capture.

A simplified communication path can look like this:
NF A → TCP → TLS → HTTP/2 → Service Request → NF B

Wireshark can still show important information such as:

• Source and destination IP addresses.
• TCP connections and ports.
• TLS handshake information.
• TLS versions and cipher suites.
• Certificates and certificate-related information exposed during the handshake.
• HTTP/2 connection behavior.
• Packet timing and retransmissions.
• Connection failures and resets.

However, TLS encryption prevents Wireshark from simply displaying the protected application payload.
This is why engineers need to understand both the 5G protocol stack and the TLS session that protects the communication.

---

How TLS Decryption Works in an Authorized Test Environment​

For legitimate engineering, troubleshooting, or security analysis, TLS traffic can be decrypted when the required session secrets are available through an authorized mechanism.
One common approach is to configure the application or test environment to export TLS session keys to a key-log file. Wireshark can then use that file to decrypt supported TLS sessions.

The general workflow is:

1. Capture the traffic between the relevant Network Functions.
2. Configure the test environment to generate TLS session secrets.
3. Save the secrets in a key-log file.
4. Load the key-log file into Wireshark.
5. Open the packet capture.
6. Inspect the decrypted protocol traffic.
7. Compare the observed messages with the expected 5G service flow.

This approach is different from trying to "break" TLS. The goal is to provide Wireshark with session secrets that were legitimately generated and exported by an environment you are authorized to analyze.

For TLS 1.3 in particular, having the appropriate session key material is important because the older practice of decrypting sessions with a server's private RSA key does not generally work with modern TLS 1.3 traffic.

---

Understanding NF-to-NF Security​

A 5G Core deployment can contain many Network Functions, including components such as the AMF, SMF, PCF, UDM, AUSF, and NRF.
Communication between NFs may involve multiple security mechanisms, depending on the deployment and applicable 3GPP requirements.

When investigating an encrypted connection, an engineer should understand:

• Which NF initiated the connection.
• Which NF received it.
• Which service is being requested.
• How the TLS session was established.
• Which certificates are involved.
• Whether certificate validation is working correctly.
• Which HTTP/2 streams belong to the relevant request.
• Whether the observed behavior matches the expected architecture.

This context is essential because a packet capture without knowledge of the expected service flow can be difficult to interpret.

---

What to Look for in a 5G Wireshark Trace​

Once the traffic is available in readable form, the analysis becomes much more useful.
Look for:

• Unexpected communication between Network Functions.
• Repeated connection failures.
• Abnormal TLS handshake behavior.
• Invalid or unexpected certificates.
• Unusual HTTP/2 requests.
• Unexpected HTTP status codes.
• Repeated requests that do not match the expected procedure.
• TCP retransmissions or connection resets.
• Sudden changes in traffic volume or timing.
• Messages that do not fit the expected 5G service flow.

A suspicious packet does not automatically mean that the network has been compromised. Protocol errors, configuration problems, certificate issues, and interoperability problems can produce similar symptoms.
The correct approach is to correlate the packet capture with logs, configuration, network topology, and the expected 3GPP procedure.

---

From Packet Capture to Security Analysis​

Wireshark is not a replacement for a complete 5G security monitoring system. Its value is in giving engineers detailed visibility into individual network conversations.
A useful investigation can follow this sequence:

1. Identify the traffic. Determine which NFs are communicating.
2. Understand the protocol. Identify TCP, TLS, HTTP/2, and the relevant service.
3. Establish the expected behavior. Determine what the normal procedure should look like.
4. Analyze deviations. Investigate unexpected messages, connections, or timing.
5. Correlate the evidence. Compare the trace with NF logs and other monitoring data.
6. Validate the conclusion. Determine whether the behavior is a configuration issue, protocol problem, or genuine security event.

This distinction is important when investigating possible injection, manipulation, or unauthorized communication. A reliable security analysis should be based on multiple pieces of evidence rather than a single packet.

---

5G Core Security Requires Continuous Monitoring​

Securing a 5G Core is not simply a matter of configuring TLS and certificates once.
Network Functions, certificates, services, software versions, configurations, and traffic patterns can change over time. Engineers therefore need to understand both normal protocol behavior and the security mechanisms protecting that communication.

The ability to read a trace, understand an HTTP/2 service flow, interpret TLS behavior, and recognize deviations from the expected protocol sequence is an important part of modern 5G Core troubleshooting and security analysis.

For engineers working with 5G Core networks, learning how to connect 3GPP procedures, NF communication, TLS, HTTP/2, and packet analysis provides a much clearer view of what is happening inside the network.

---

Frequently Asked Questions​

------------------

Can Wireshark decrypt TLS 1.3 traffic?​

Yes, when the required TLS session secrets are available through an authorized analysis or test environment. A normal packet capture alone does not provide enough information to decrypt TLS 1.3 application data.

Can I decrypt 5G HTTP/2 traffic using Wireshark?​

Yes, if the TLS session can be legitimately decrypted. Once Wireshark has the appropriate session key material, it can decode the protected HTTP/2 traffic when the relevant protocols are supported.

Does encrypted traffic mean Wireshark is useless?​

No. Even without decryption, Wireshark can provide valuable information about TCP connections, TLS handshakes, certificates, timing, retransmissions, connection failures, and other network behavior.

Is every unusual packet a security attack?​

No. Unexpected traffic can result from configuration errors, interoperability problems, failed procedures, certificate issues, software bugs, or genuine security events. The trace should be correlated with other evidence before drawing a conclusion.

Why is 5G Core traffic different from older signaling analysis?​

5G Core uses a Service-Based Architecture with IP-based communication and service APIs. This means engineers often need to analyze layers such as TCP, TLS, and HTTP/2 in addition to understanding the underlying 5G service procedures.