TLS Visibility

The telecom sensor instruments TLS libraries directly on each monitored node, classifying every active connection as plaintext, uprobe-covered TLS, or opaque TLS. This classification drives compliance checks, anomaly scoring, and investigation context without requiring decryption or private key access.

Requires: Telecom sensor flavor. TLS uprobe coverage is automatically activated at sensor startup; no additional configuration is needed.

---

How TLS uprobe coverage works

At sensor startup, the sensor scans /proc for running binaries and inspects each binary for linked TLS libraries. When a supported library is found, the sensor generates a tracing policy YAML file for that library and writes it to compiled-policies/tls-uprobe-*.yaml. The policy is loaded automatically and instruments the library functions in the running process using uprobes (user-space probes).

This approach does not require configuration. It runs automatically for all processes on nodes where the telecom flavor is deployed.

Supported TLS libraries and hooked functions

OpenSSL (libssl.so)

Function	Direction
SSL_write, SSL_write_ex	Outbound: data before encryption
SSL_read, SSL_read_ex	Inbound: data after decryption
BIO_write, BIO_read	BIO layer (low-level crypto transport)

GnuTLS (libgnutls.so)

Function	Direction
gnutls_record_send, gnutls_record_send2	Outbound
gnutls_record_recv	Inbound

Go TLS (Go standard library crypto/tls)

Function	Direction
conn.Write	Outbound
conn.Read	Inbound

BoringSSL (libcrypto.so, Google's OpenSSL fork)

Function	Direction
SSL_write	Outbound
SSL_read	Inbound

If a binary does not link any of these libraries, no uprobe policy is generated for that process and the sensor falls back to network-layer coverage only.

---

Coverage classification

Every active connection on a monitored process is classified into one of four coverage states:

Classification	Condition	Meaning
Plaintext	H2C frames observed (cleartext HTTP/2) or raw TCP on a known protocol port	Connection is unencrypted; eBPF has full payload visibility
OpenSslTls	SSL_write uprobe fired for this connection	TLS library is hooked; payload is capturable before encryption and after decryption
OpaqueTls	TCP connection to a known TLS port (443, 8443, etc.) but no SSL_write fired	Connection is TLS but the library is not hooked; connection metadata visible, payload not
Unknown	TCP connection with no data signal yet	Classification pending; typically resolves on the next heartbeat interval

The coverage classification is assigned per connection and reported in the tls_inventory_report heartbeat field alongside the NF role, port, interface name, and a coverage_gap boolean.

Example heartbeat record

{
  "tls_inventory_report": {
    "nf_tls_postures": [
      {
        "nf_role": "SMF",
        "port": 7777,
        "tls_posture": "openssl_tls",
        "interface_name": "SBI",
        "coverage_gap": false
      }
    ]
  }
}

---

SBI compliance check

3GPP TS 29.501 requires mutual TLS (mTLS) for all SBI (Service-Based Interface) connections between 5G Core network functions. The sensor enforces this requirement at detection time.

SBI ports monitored: 7777 (Open5GS/Free5GC default) and 29500-29599 (3GPP standard range)

Condition	Alert severity	Meaning
SBI port classified as Plaintext	Critical	NF-to-NF SBI traffic is unencrypted; 3GPP TS 29.501 violation
SBI port classified as OpaqueTls	High	TLS is in use but library is not hooked; coverage gap on mTLS interface

These alerts feed directly into the telecom anomaly scoring system. A Plaintext SBI finding contributes a critical-weight factor to the node's telecom risk score.

---

Compliance control mapping

TLS posture data contributes evidence to two compliance frameworks:

3GPP TS 33.117

Control	What TLS data contributes
3GPP_4_2_5B	SBI/NF API interface coverage; evidence from tls_inventory_report

NIS2 Directive (Telecom)

Control	What TLS data contributes
NIS2_H	Cryptography and SBI TLS monitoring; plaintext or opaque findings trigger evidence gaps

---

Heartbeat field reference

The tls_inventory field in the sensor heartbeat (also referenced as tls_inventory_report) contains the full TLS posture inventory for all monitored processes on that sensor.

Per-posture record fields:

Field	Type	Meaning
nf_role	String	NF role of the process (e.g., SMF, AMF, UPF)
port	Integer	Port number of the TLS connection
tls_posture	String	Classification: plaintext, openssl_tls, opaque_tls, or unknown
interface_name	String	Interface label (e.g., SBI, N4, NGAP)
coverage_gap	Boolean	true when posture is opaque_tls on a compliance-relevant interface

---

AI assistant tool

Ask the AI assistant: "Show TLS inventory for AMF nodes."

The AI assistant get_tls_inventory tool queries the current TLS posture state for a sensor or across the fleet, surfacing which NF roles are serving SBI over plaintext or have opaque TLS coverage gaps before you enable enforcement.

---

TLS visibility and enforcement

TLS posture directly affects the quality of enforcement on telecom nodes. When a node has OpaqueTls coverage on a critical interface (SBI, N4, or a management interface), the sensor can still detect process behavior, privilege events, and file integrity anomalies. What it cannot do with opaque coverage is correlate payload-level protocol behavior with those events.

Before enabling enforcement mode on an AMF, SMF, or UPF node, confirm that the SBI interface shows openssl_tls or plaintext coverage. Enforcement on a node with opaque SBI coverage means the system is acting on behavioral signals without full protocol context.

---

Relationship to O-RAN WG11 controls

TLS posture findings on O-RAN management interfaces contribute evidence to:

• ORAN_E2: E2 interface peer verification (TLS coverage on E2AP connections)
• ORAN_O1: O1 management interface security (NETCONF over SSH on port 830 is tracked separately; TLS on O1 REST interfaces contributes here)
• ORAN_XAPP: xApp API security (TLS coverage on E42 and xApp-to-RIC connections)

---

Operational guidance

StaticTLS libraries: Some vendor NF builds link TLS statically rather than as a shared library. When the library is statically compiled into the binary, the standard uprobe approach cannot hook it because there is no libssl.so or libgnutls.so file. These connections will be classified as OpaqueTls regardless of what TLS version they use. This is a known limitation of the uprobe approach and is reflected in the coverage_gap field.

Container environments: On Kubernetes nodes, the sensor instruments libraries inside container processes the same way it instruments host processes. TLS libraries inside container file systems are resolved through the container's namespace. If a container runs a stripped image without the shared library visible to uprobe resolution, the connection will be classified as OpaqueTls.

Go TLS: Go TLS (crypto/tls) is frequently used by open-source 5G implementations (Free5GC, for example). The sensor instruments Go TLS through the gotls_uprobes.rs module using method-level uprobes on conn.Write and conn.Read. Go binary versions that use function inlining may prevent uprobe attachment; in those cases the classification falls back to OpaqueTls.

Resolving opaque TLS gaps on SBI: If SBI connections show OpaqueTls, verify that the NF binary links against OpenSSL, GnuTLS, Go TLS, or BoringSSL as a shared library. Switching from a statically linked to a shared library build resolves the gap. Contact the NF vendor if the build configuration is not user-controllable.

---

Limitations

• Statically linked TLS libraries cannot be hooked: When a vendor NF links OpenSSL, GnuTLS, or BoringSSL statically into its binary, there is no shared library file for the uprobe to attach to. These connections are classified as OpaqueTls regardless of TLS version. The coverage_gap: true field indicates this condition. Contact the NF vendor to request a shared-library build.
• Container images with stripped libraries produce OpaqueTls: On Kubernetes nodes, the sensor resolves TLS libraries through each container's namespace. A container that does not include the shared library files (libssl.so, libgnutls.so, etc.) in its image will be classified as OpaqueTls even if the binary uses TLS.
• Go TLS uprobe may fail with inlined binaries: Go's compiler can inline the conn.Write and conn.Read methods used for uprobe attachment. When inlining occurs, the uprobe cannot attach and the coverage falls back to OpaqueTls. This affects some production builds of Go-based 5G implementations.
• TLS classification only applies to processes monitored by the sensor: TLS traffic from processes that started before the sensor enrolled, or that run outside the sensor's process scope, is not classified. The tls_inventory_report reflects only currently monitored connections.
• No payload decryption is performed: TLS visibility classifies the coverage state and detects SBI compliance violations (plaintext or opaque coverage on SBI ports). It does not decrypt or store TLS payload content at any coverage level.

---

Further reading

• O-RAN WG11 Compliance
• 5G Core (AMF / SMF / UPF)
• Compliance (CIS / NIS2 / ETSI)
• Enforcement Reference
• Telecom Overview
• 3GPP TS 29.501 - 5G System Principles; Stage 3 (SBI mTLS requirement)
• RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3