Classify & Manage TLS 1.3 Traffic
TLS 1.3 enhances security by introducing safer key exchange methods. One key extension, Encrypted Client Hello (ECH), further secures the client-server handshake. Natively supported by iOS, Android, and Firefox, ECH wraps the standard Server Name Indication (SNI) within an encrypted key exchange, using an outer SNI to obscure the specific service being requested. Previously, these details were essential for identifying, routing, and managing mobile data traffic. Now, as major hosting providers implement ECH on the server side, communication service providers (CSPs) must adapt to this new reality to effectively manage traffic.
Managing TLS 1.3 & ECH
Over 96% of mobile data traffic is encrypted, making it crucial for telecom teams to understand TLS 1.3 and its extensions to effectively manage data flows. TLS 1.3 (RFC 8446) enhances security with zero-round trip (0-RTT) handshakes, updated cipher suites that exclude outdated algorithms, and a simplified key exchange process. Additionally, TLS 1.3 supports extensions (RFC 6066) that further refine the client-server handshake.
One key extension, Encrypted Client Hello (ECH), has gained adoption among content and client providers, improving upon the earlier Encrypted SNI. Traditionally, the Server Name Indication (SNI) is visible in plaintext, allowing telecom providers to monitor traffic flows and enforce access policies. However, ECH encrypts this information, complicating traffic analysis.
Since services often host multiple domains, ECH introduces an “outer” and “inner” SNI. The outer SNI identifies the server, while the inner SNI specifies the exact service. For ECH to function, both the client and server must support the full handshake. While browsers and apps now support ECH, adoption on the server side has been slower, with large CDN and cloud providers still experimenting with implementation.
The key exchange is in two stages as illustrated in the call flow below
In the ECH extension the first SNI is for the hosting server/client-facing server – the actual service being used is encoded (MYSERVICE.COM) and only decoded by the Client Facing Server.
Enea Traffic Management
The traffic management tools from Enea can handle the increasing presence of ECH based traffic in the following key ways
#1 Traffic Classification – using additional AI Learning capabilities and advanced traffic profiling (e.g. for large content providers) traffic can be classified for the CSP Network management
#2 Selective Policy Enforcement – depending on user group selective management may be required. E.g. in the case where users are under 16 a policy may be block ECH extensions being used, in order to protect users from harmful content (as part of their agreed policy for data access).
#3 Fraud Detection and access profiling – analysing where users are trying to bypass regulator and/or law enforcement controls (e.g. pirating sports content)
-
Enea’s technology allows us to effectively manage all our streaming data, including encrypted video, resulting in a very positive impact on subscriber QoE
-
TELUS is proud to partner with Enea and give our customers a better experience while watching videos
-
Secure Traffic Manager and RAN Congestion Manager effectively manage encrypted and non-encrypted traffic, reduce RAN congestion and improve subscribers’ quality of experience.
TLS 1.3 & ECH Frequently Asked Questions
TLS 1.3 is the latest extension to the transport layer security protocol (TLS) which secures internet and data traffic globally; its fundamental principle is based on public key exchange. The encryption level, cipher and public keys are negotiated between client and server in an unencrypted ‘handshake’ exchange. The latest version of the protocol improves the available ciphers and also improves on the handshaking protocol..
TLS exchanges, in the past, have been vulnerable to so-called ‘man in the middle’ attacks where the handshake is intercepted and emulated by a middle box. This is largely no longer possible in mobile data as the apps and browsers in mobile devices are sensitive to the authenticity of the server side certificate and will issue multiple warnings if the secure handshake is attacked in this way. Users will see their link is not secure and as such this renders an attack useless.
UDP is a connectionless protocol that exchanges packet by packet; TLS 1.3 is designed to work on TCP (which is about half of all traffic). Secure connections on UDP QUIC require specific application encoding or will use the datagram transport level security (DTLS) protocol.
It is another step in client-server communication that facilitates privacy and also enables additional security for a server engaged in virtual hosting. However there are concerns that it disables legitimate, regulated, capabilities to verify content destinations as part of user’s access policy or because the spectrum / service is regulated by regional communications authority.
You can see from the protocol stream that ECH is being attempted; however it is more difficult as there is something called ECH ‘Grease’d in which the protocol extensions used for ECH are in the stream regardless of whether ECH is being supported by the server side. This is an attempt to accelerate the adoption of ECH and confuse protocol analysers in networks or at enterprise sites. The use of ECH in data traffic can be determined from DNS traffic as well.
It terms of the large web content providers it has yet to be fully adopted (it is supported by IOS and Android, Edge, Firefox); it does also rely on DNS to obtain encryption key so in some cases can’t be enabled unless this is also supported; Additionally large hosting platforms like CloudFlare have adopted it for their free tier services. It is becoming an RFC standard. We have seen other commentary in the media in respect of ECH traffic in Spain pirating LaLiga (football), there have been recent court judgements that are enabling Telecom Operators to increase enforcement level to defend against pirated content.