I’d like to ask whether Apple plans to enable Encrypted Client Hello (ECH, RFC 9849) opportunistically by default across the iOS/iPadOS system networking stack.
Apple already exposes ECH support through sec_protocol_options_set_enable_encrypted_client_hello(), but there currently appears to be no system-wide preference, configuration profile, or MDM policy to enable ECH for normal system networking clients such as URLSession, CFNetwork, WebKit/Safari, and other apps relying on Apple’s networking stack.
I tested this with a working ECH deployment:
A domain publishes a valid DNS HTTPS/SVCB record containing an ech parameter.
The corresponding TLS endpoint supports ECH.
iOS successfully queries and receives the HTTPS/SVCB record.
Safari / normal system networking clients then connect to the domain.
Packet capture still shows the real SNI in the plaintext ClientHello, and ECH is not attempted.
If the same connection is explicitly configured to enable ECH at the TLS protocol-options level, ECH can be used successfully.
It would be useful if iOS/iPadOS could:
Opportunistically enable ECH by default whenever TLS 1.3 and a valid ECHConfig are available.
Optionally provide a system-wide / MDM policy for enabling ECH.
Ideally provide an “ECH required” policy that fails closed rather than falling back to plaintext SNI.
This would improve hostname privacy for applications using the system networking stack without requiring every application developer to explicitly opt in.
I have submitted this through Feedback Assistant as:
FB24334961 — Enable Encrypted Client Hello (ECH, RFC 9849) by default for system TLS connections
Has anyone found an existing system-level way to enable ECH, or does anyone know whether Apple plans to make this the default behavior?
0
0
221