TLS 1.3, QUIC, HTTP/3, encrypted DNS, and Encrypted Client Hello increasingly conceal application and transport information that network operators traditionally used for troubleshooting, security inspection, filtering, performance optimization, and policy enforcement. Here is a little reference chart:
This produces two defensible but conflicting positions:
- Privacy position: Networks should carry packets without revealing users’ destinations, applications, content, or behavior.
- Operational-security position: Enterprises, service providers, schools, and security teams need sufficient visibility to detect malware, enforce policy, diagnose failures, and protect users.
For most of the Internet’s history, and certainly for my career, network troubleshooting has depended heavily on visibility – visibility of data and packets on the network. As technician’s and engineers, we could capture traffic, identify the application protocol, examine transport-layer behavior, inspect DNS requests, and often see exactly what a client and server were exchanging. That visibility helped all network professionals diagnose failures, detect malicious activity, enforce organizational policies, and understand how applications were using the network.
That model has been, and is, rapidly changing.
Internet protocols are increasingly designed so that only the communicating endpoints can understand the exchange. TLS 1.3, HTTPS, QUIC, HTTP/3, encrypted DNS, VPNs, and Encrypted Client Hello are steadily reducing the information available to devices and people located between the endpoints. This movement toward pervasive encryption provides significant privacy and security benefits, but it also creates one of the most difficult debates in modern networking:
How do we protect users from surveillance and interception of their data and personal information without making networks impossible to operate, secure, and troubleshoot?
Let’s Discuss Why More Encryption Is Necessary
The argument for stronger encryption is a compelling one. Internet traffic may pass through broadband providers, wireless networks, transit carriers, cloud platforms, content-delivery networks, and other infrastructure before reaching its destination. Any unencrypted information visible along that path may potentially be collected (stolen), analyzed, altered, or misused.
In 2014, the Internet Engineering Task Force declared in RFC 7258 that pervasive monitoring should be treated as a technical attack and mitigated in Internet protocol design. That position helped accelerate an industry-wide shift toward encrypting not only application content, but also additional information about connections and user behavior.
Encryption protects far more than passwords and financial transactions. A person’s DNS queries, websites visited, applications used, communication patterns, and connection metadata can reveal sensitive information even when the actual message content remains hidden. RFC 9076, for example, explains that DNS activity can expose information about users and the services they access.
From the user’s perspective, the objective is straightforward: the network should transport communications without unnecessarily observing them.
Encryption Is Moving Deeper into the Protocol Stack
Traditional HTTPS encrypted the application payload, but several useful pieces of metadata remained visible. Network tools could normally identify the TCP connection, observe sequence and acknowledgment numbers, calculate retransmissions, examine round-trip times, and see the hostname supplied through the TLS Server Name Indication field.
Newer protocols reveal considerably less. QUIC is a secure transport protocol that operates over UDP and incorporates TLS-based security directly into the transport. It provides multiplexed streams, low-latency connection establishment, path migration, and confidentiality and integrity protections. HTTP/3 maps HTTP communications onto QUIC rather than traditional TCP.
QUIC encrypts much of the transport information that network professionals previously used for passive analysis. A packet capture may still show source and destination IP addresses, UDP port numbers, packet lengths, timing, and certain connection identifiers, but many loss-recovery, stream-management, and connection-control details are available only to the endpoints. The IETF’s QUIC manageability guidance acknowledges that this reduced wire image changes what network devices and passive monitoring systems can observe.
DNS is undergoing a similar transformation. DNS over TLS, DNS over HTTPS, and DNS over QUIC protect DNS transactions from passive observation while they travel between clients and recursive resolvers. For example, DNS over QUIC provides confidentiality through QUIC while attempting to retain performance characteristics similar to conventional DNS over UDP.
A major additional step occurred in March 2026 with the publication of RFC 9849, TLS Encrypted Client Hello, or ECH. ECH allows a client to encrypt sensitive portions of the TLS ClientHello message, including the requested server name and potentially revealing protocol-negotiation information. RFC 9848 defines how clients can obtain ECH configuration information through DNS service-binding records.
Putting them together, these technologies make it increasingly difficult for an intermediate network observer to determine not only what a user is doing, but sometimes which specific service the user is contacting.
The Service Provider/Network Operator’s Dilemma
The loss of visibility has real operational consequences for the folks that provide services to end users, especially when they have issues.
We have always used packet analysis (with tools like Wireshark) to locate latency, packet loss, retransmissions, failed handshakes, application delays, DNS problems, congestion, and asymmetric routing. Security teams use network data to detect command-and-control activity, malware delivery, data exfiltration, unauthorized applications, and policy violations. Schools, hospitals, businesses, and government organizations may also have legal or contractual responsibilities to monitor or control traffic on networks they operate.
When protocols conceal more of their operation, traditional monitoring systems may no longer provide a complete explanation of what happened. A network engineer may see a series of UDP packets but be unable to inspect the QUIC streams inside them. A security appliance may recognize an encrypted DNS connection but not the individual domain queries. An administrator may know that a client contacted a large cloud platform but not which hosted service was requested.
The problem is not simply that technicians can no longer read application content. In many environments, they should not be reading it. The deeper problem is that encryption may also conceal the diagnostic and security signals required to determine whether the network or application is functioning correctly.
The IETF has recognized this tension for years. RFC 8404 discusses both the need to protect users from pervasive monitoring and the need to avoid making networks unmanageable. This document does not treat privacy and network operation as mutually exclusive goals; instead, it argues that both must be considered during protocol design and deployment.
Should Organizations Decrypt Their Own Traffic?
Some organizations respond by using TLS inspection. A managed device trusts an organizational certificate authority, allowing a security appliance to terminate, inspect, and then re-encrypt selected connections.
Decryption can restore visibility, but it introduces additional concerns. The inspection system becomes a highly sensitive intermediary. Whatever system is used must securely handle certificates, keys, decrypted content, logs, and user information. Further, this may also create compatibility problems with certificate pinning, mutual authentication, QUIC, privacy-sensitive applications, or devices outside the organization’s administrative control.
There is also an important distinction between monitoring a managed corporate device on a privately operated network and monitoring the general public. An employer may have a legitimate reason to protect company systems and information, but users should be clearly informed about what is inspected, why it is inspected, how long the information is retained, and who can access it.
Blanket decryption is therefore neither technically simple nor ethically neutral.
Visibility Is Evolving, Not Disappearing
The future of troubleshooting will require a shift from unrestricted packet inspection toward cooperative and endpoint-assisted observability.
Network professionals will increasingly depend on:
- Endpoint packet captures and browser or application logs
- Flow records, packet timing, volume, and connection metadata
- DNS and proxy logs from organization-controlled services
- QUIC-aware telemetry exported by clients and servers
- Application performance monitoring
- Synthetic testing and active measurements
- Correlation across network, endpoint, cloud, and security platforms
Of course, packet capture will remain essential, but analysts will need to understand exactly what can and cannot be concluded from encrypted traffic. A capture may still prove that loss, delay, fragmentation, path changes, or connection failures occurred. It may not reveal the application’s internal state or the precise transaction that triggered the problem.
That distinction must become part of modern packet-analysis training.
Finding the Appropriate Balance
So, encryption is not the enemy of network engineering. It protects users, applications, businesses, and critical infrastructure from interception and manipulation. Weakening encryption to make monitoring easier would expose everyone—not only criminals or malicious actors—to greater risk.
At the same time, protocol designers and application developers should not assume that all network visibility is inherently abusive. Networks must still be operated, measured, defended, and repaired. Useful diagnostic information should be available through secure, intentional, and accountable mechanisms rather than through accidental exposure on the wire.
The most practical path forward is not unrestricted surveillance or complete network blindness. It is selective, consent-based, and purpose-limited visibility, supported by telemetry from the systems that actually possess the encryption keys.
Therefore, end-to-end encryption is changing the networking profession. The successful network technician/engineer of the future will not simply capture more packets. They will combine the evidence still visible on the network with endpoint telemetry, application behavior, active testing, and a precise understanding of modern encrypted protocols.
The packets are still there. The challenge is learning what they can—and can no longer—tell us.
If you would like to help support the continued development of independent networking, broadband, Wi-Fi, VoIP, and packet analysis content, please consider joining our Patreon community where you will gain access to exclusive technical resources, downloadable labs and PCAPs, bonus course content, troubleshooting guides, and additional member-only material. Comments and technical discussion are always welcomed at our Patreon community or on our Discord server. You can also support our work by simply buying us a coffee — every contribution helps us continue creating practical, real-world network science education for professionals and enthusiasts alike.