ECH Hides the Visit, Not the Domain's Existence

Two fresh platform changes make an apparent contradiction useful.

On 14 August, Vercel added Encrypted Client Hello support for domains managed by Vercel DNS. When a compatible browser and DNS path use ECH, a passive network observer sees a connection to Vercel's shared vercel-ech.com name instead of the visitor's intended hostname.

One day earlier, Cloudflare made Certificate Transparency Monitoring generally available across all plans. It alerts an opted-in domain owner when a certificate covering the monitored domain appears in public Certificate Transparency logs, while filtering certificates Cloudflare issues on the owner's behalf.

These features move visibility in opposite directions for good reasons. ECH makes one person's destination less visible on the network path. Certificate Transparency makes certificate issuance for a domain publicly auditable. Neither feature makes a domain secret, proves that a route is legitimate, or confirms that every visitor received the same privacy protection.

The repeated angle to avoid

The ten most recent posts here covered deployment-level authentication, Shopify checkout experiments, agent-plugin trust, context copies, form-security states, server-side agent conversion tracking, AI work receipts, prototype exits, billing handovers, and code-quality policy. Older overlapping posts covered public-surface monitoring, DNS-backed email authentication, deployment contracts, TLS security scans, and cache variants.

The weak version of this article would repeat the old X needs Y formula: encrypted connections need monitoring. The sharper thesis is that ECH deliberately reduces one source of passive hostname evidence while Certificate Transparency deliberately expands another source of public domain evidence. Operators should stop treating "HTTPS works" as one state and instead prove connection privacy, certificate legitimacy, DNS advertisement, CDN routing, and application authority independently.

Fresh evidence and background context

The source map separates this week's platform evidence from protocol and implementation context:

Source	Freshness	What it contributes
Vercel CDN ECH announcement	14 August 2026	Automatic ECH support for domains on Vercel DNS, the shared public name, and current browser support
Cloudflare CT Monitoring GA	13 August 2026	Availability across plans, filtering of Cloudflare-managed issuance, and more actionable alerts
Vercel CDN encryption documentation	Current primary documentation	HTTPS DNS-record discovery, platform-managed enablement, supported clients, and ordinary TLS fallback
Cloudflare ECH documentation	Current primary documentation	Inner and outer ClientHello behaviour, privacy limits, and enterprise-network implications
TLS Encrypted Client Hello, RFC 9849	Background, March 2026	The protocol threat model, anonymity-set goal, DNS dependency, deployment risks, and related privacy leaks
Cloudflare CT Monitoring documentation	Updated 13 August 2026	What creates an alert, routine versus concerning issuance, and limits such as lookalike domains

The new information surplus is the evidence model between these sources. ECH changes what an observer can infer about a connection. CT monitoring changes what an operator can learn about certificate issuance. A safe deployment needs both forms of evidence without confusing either with DNS ownership, application authorization, or live routing.

ECH encrypts a routing hint that HTTPS previously exposed

Ordinary HTTPS already encrypts the HTTP request path, headers, response, cookies, and body after the TLS connection is established. The awkward remaining signal has been the Server Name Indication in the ClientHello. A shared CDN needs that hostname early enough to select the correct TLS configuration, so the name has traditionally been visible before the encrypted application exchange begins.

ECH changes that flow:

client resolves the destination
  -> HTTPS DNS record supplies an ECH configuration
  -> client builds an inner ClientHello with the real hostname
  -> client encrypts it inside an outer ClientHello
  -> outer hello names the provider's shared public endpoint
  -> provider decrypts the inner hello and routes the connection
  -> normal HTTPS application traffic continues

For Vercel's rollout, the outer name is vercel-ech.com. A compatible observer can still see that the client connected to Vercel infrastructure. It should no longer receive the intended customer hostname from the SNI field when ECH succeeds.

That is meaningful privacy, especially where a hostname can reveal a sensitive interest before the visitor loads a page. It is not anonymity from every participant. The DNS resolver may know the requested name. The CDN has to recover the inner name to route the connection. The application receives the host and request. IP addresses, timing, unique infrastructure, account login, cookies, and later application behaviour can expose other facts.

RFC 9849 says ECH is not sufficient by itself to conceal server identity. Plaintext DNS and visible server IPs can still reveal it. The protocol's narrower goal is to make destinations within a provider's anonymity set indistinguishable at the TLS handshake to the attacker described by the standard.

Use the narrow claim: ECH can hide the intended hostname from a passive observer on the connection path when the complete client, DNS, and server path supports it.

Privacy success and connection success are different states

Vercel's documentation says browsers obtain ECH configuration from the domain's HTTPS DNS record. It also says that a browser or resolver without ECH support falls back to a standard TLS handshake without losing TLS security.

The last phrase needs careful interpretation. The fallback connection can still be authenticated and encrypted using ordinary TLS. The visitor does, however, lose the SNI privacy benefit for that connection.

request outcome: page loaded securely
privacy outcome: ECH accepted | ordinary SNI exposed | unknown

A synthetic check that receives HTTP 200 proves reachability through the test client's path. It does not prove ECH was advertised, attempted, accepted, or used by customer browsers. An uptime monitor may use a resolver or TLS library with no ECH support and still report perfect availability.

The reverse also matters. A DNS or ECH configuration problem can affect compatible clients differently from older clients. A test fleet containing only one browser, resolver, office network, or VPN can miss the split.

Keep at least four client cohorts in the acceptance plan:

Cohort	What it exercises	Failure worth detecting
Current ECH-capable browser with encrypted DNS	Intended privacy path	Missing, stale, or rejected ECH configuration
Current browser using the normal local resolver	Typical customer or office path	Resolver omits or alters HTTPS records
Client without ECH support	Ordinary TLS fallback	Site works only for the newest client path
Managed, filtered, VPN, or enterprise network	Policy and middlebox compatibility	Hostname policy depended on plaintext SNI and now blocks or misroutes traffic

Cloudflare's ECH documentation explains why the fourth cohort exists. Networks that must enforce domain policy may apply it at DNS, and some can suppress HTTPS records or use browser canary behaviour to prevent ECH. That may be a deliberate local policy rather than a fault in the website. The operator still needs to know whether an important customer, staff, checkout, booking, or support journey fails on that path.

ECH does not make the domain or certificate private

Certificate Transparency solves a different trust problem. Publicly trusted certificate authorities submit certificates or precertificates to append-only CT logs so browsers and monitors can detect issuance that should not have happened silently.

A domain can therefore have both properties at once:

• an observer cannot read the real hostname from one successful ECH handshake;
• a researcher or monitor can discover that a certificate covering the hostname was logged;
• a DNS resolver can answer a query for the hostname;
• the CDN and application can observe requests for the hostname;
• a search engine, sitemap, backlink, email, or public page can reveal the hostname normally.

That is not a contradiction. ECH protects a visitor-to-destination relationship on a particular network path. CT protects the certificate ecosystem by making issuance reviewable. Neither promises that the domain name itself is confidential.

This distinction matters for preview, staging, partner, campaign, and internal-tool hostnames. A hard-to-guess subdomain is not a security boundary. ECH does not turn it into one. A CT log may expose certificate coverage, and the application still needs Access, authentication, authorization, or network restrictions appropriate to its data and actions.

It also matters for monitoring language. A CT alert means a certificate covering the monitored name was logged. It does not prove that an attacker controls DNS, serves the certificate, reaches the origin, or can perform an application action.

Cloudflare's documentation recommends checking the domain, issuer, and whether the organisation or one of its services requested the certificate. Most alerts can be routine: a hosting migration, managed renewal, uploaded custom certificate, backup certificate, or shared certificate can create legitimate issuance. Conversely, CT monitoring does not detect a lookalike such as examp1e.com when the owned domain is example.com.

Use CT as an issuance signal that starts triage, not as a compromise verdict or complete brand-abuse monitor.

Automatic platform enablement creates configuration drift without an app diff

Vercel manages ECH at the platform level and enables it automatically where available for eligible Vercel DNS domains. That removes application implementation work, which is a benefit. It also means the effective network behaviour can change without a pull request to the website.

Several ordinary operations can then create a silent privacy change:

1. A DNS migration changes eligibility. The A, AAAA, or CNAME route may keep the website reachable while the expected HTTPS record or ECH configuration changes.
2. A resolver path suppresses HTTPS records. The page loads through ordinary TLS, so availability dashboards remain green while SNI privacy disappears for that cohort.
3. A provider changes ECH configuration. Platform management should handle rotation, but cached or altered DNS answers can create client-specific retries or fallback.
4. A corporate network still filters by plaintext SNI. ECH-capable clients may behave differently from devices governed by DNS policy or older inspection tooling.
5. An alternate hostname is missed. The apex uses managed DNS and ECH while www, a checkout subdomain, a booking domain, or an old campaign hostname follows another path.

The implementation consequence is not to pin platform internals in application code. It is to put transport privacy in the domain inventory and test it when DNS, CDN, certificate, proxy, VPN, or network policy changes.

Build an evidence matrix instead of one HTTPS checkbox

A domain review should identify what each observation proves and what it leaves open.

Observation	It can prove	It cannot prove
HTTPS DNS record advertises an ECH configuration	This DNS answer offers ECH metadata	The browser received it, trusted it, or negotiated ECH
Browser or controlled client confirms ECH acceptance	This client used ECH on this network path	Every customer, resolver, hostname, or future connection will use it
HTTP 200 over TLS	The tested route returned a response securely	SNI was hidden, the response was correct, or the user was authorized
CT alert arrives	A logged certificate covers the monitored domain	The issuance is malicious or the certificate is serving traffic
CDN project lists the hostname	The platform intends to route that name to a project	DNS currently points there or the application enforces the right access policy
Application log records the host	The request reached an application path that observed that host	What a passive network observer saw before the request arrived
Passive capture shows only the shared public name	ECH concealed SNI in that tested connection	DNS, IP, timing, cookies, CT logs, or the provider reveal nothing else

This prevents the most common category error: promoting one layer's success into a claim about all the others.

A domain transport receipt

Keep a compact record for customer-facing and sensitive operational hostnames. It can live beside the domain inventory, deployment runbook, or infrastructure configuration.

domain_transport_receipt:
  hostname: booking.example.com
  business_surface: customer_booking
  owner: web_operations
  dns:
    authoritative_provider: managed_dns_provider
    expected_cdn: hosting_provider
    https_record_expected: true
    ech_config_expected: true
  connection_privacy:
    public_ech_name: provider-shared-name.example
    supported_browser_test: passed
    normal_resolver_test: passed
    non_ech_fallback_test: passed
    managed_network_test: passed
    claim: hostname_hidden_from_passive_path_observer_when_ech_is_accepted
  certificates:
    ct_monitoring: enabled
    alert_destination: security-operations
    expected_issuers:
      - managed_hosting_ca
    migration_exception_expires: 2026-09-01
  routing:
    expected_project: customer-booking-production
    alternate_hostnames:
      - www.example.com
    preview_access: staff_identity_required
  application:
    authentication: customer_session
    sensitive_actions: server_authorized
    synthetic_journey: create_then_cancel_test_booking
  review_triggers:
    - dns_provider_change
    - cdn_change
    - certificate_issuer_change
    - vpn_or_filter_policy_change
    - new_hostname

The receipt contains no ECH private key or application secret. Its value is the join between DNS ownership, privacy expectation, certificate monitoring, route destination, access policy, client cohorts, and business journey.

Test the transition, fallback, and alert paths

A practical release check does not need to reverse-engineer every TLS packet. It does need evidence from more than one layer.

DNS and advertisement

• Query the hostname's HTTPS record through the expected public resolver and the resolver used by staff or managed devices.
• Confirm the expected ECH parameter is advertised where the hosting platform says it should be.
• Record the result as configuration advertised, not ECH negotiated.
• Repeat for apex, www, checkout, booking, account, API, and other independently routed hostnames.

Client behaviour

• Use a current supported browser on a network path that permits ECH and confirm negotiation with the browser's network diagnostics or a controlled capture.
• Repeat with an ordinary resolver, VPN, filtered network, and non-ECH client.
• Confirm the correct certificate, application, redirect, canonical hostname, and authenticated route appear in every cohort.
• Treat ordinary TLS fallback as an availability success and a connection-privacy difference.

Certificate monitoring

• Enable CT monitoring deliberately; Cloudflare documents it as opt-in and off by default.
• Route alerts to an owned mailbox or queue rather than one developer's inbox.
• Keep expected certificate authorities and hosting services in the domain record.
• During a planned certificate or hosting migration, verify that the expected alert arrives and can be classified.
• Exercise the escalation path for an unknown issuer without assuming the alert itself proves takeover.

Application and business outcome

• Verify that ECH does not become a substitute for authentication on previews or internal tools.
• Test sensitive actions against server-side identity and resource authorization.
• Run the real customer journey—lead, booking, checkout, account login, or support request—through representative client cohorts.
• Reconcile the result in the business system rather than stopping at a successful TLS connection.

Failure modes worth reviewing

The page is green, but ECH is absent

An uptime monitor uses a client or resolver without ECH, completes ordinary TLS, and reports success. Add a separate privacy-path check and keep its status distinct from availability.

The DNS move preserves routing but drops privacy metadata

A migration reproduces A, AAAA, and CNAME records but not the platform path that supplies the HTTPS ECH configuration. The site stays live while compatible visitors return to visible SNI. Include HTTPS-record and ECH checks in DNS cutover and rollback evidence.

A privacy claim becomes universal marketing language

The site says its hostname is hidden from internet providers for every visit. Some clients use plaintext DNS, unsupported resolvers, ordinary TLS fallback, unique IP paths, or managed networks that disable ECH. State the narrower client-and-path claim the implementation can test.

A CT alert is treated as proof of compromise

A legitimate SaaS, CDN, renewal, migration, or shared certificate creates the alert. Triage issuer, requested service, SAN coverage, timing, DNS, and serving endpoints before declaring impact.

A hidden hostname is treated as a protected application

A preview or staff tool has ECH and an obscure name but no access control. Anyone who discovers the URL can still reach it. Protect the deployment and authorize application actions independently.

Hostname filtering fails on one customer network

A managed network relied on plaintext SNI while the client begins using ECH. Move intended policy toward authenticated DNS or supported endpoint controls where possible, and keep a tested recovery path for important staff and customer workflows.

Monitoring covers the apex but not the operating surface

The team watches example.com while bookings, checkout, accounts, APIs, and campaign tools use other certificate and DNS paths. Inventory every hostname by business consequence, not only by brand prominence.

The practical conclusion

Vercel's rollout closes a real privacy gap without requiring application code. Cloudflare's CT Monitoring release makes another useful control easier to adopt. The two should coexist because they protect different relationships.

ECH reduces what a passive observer can learn about one supported connection. Certificate Transparency makes certificate issuance reviewable. DNS still advertises how clients find the service. The CDN still routes the hostname. The application still decides who can see data or perform work. Business monitoring still has to prove that a booking, order, lead, or login completed correctly.

The durable operating model is therefore layered: advertise ECH, verify it in supported cohorts, preserve ordinary TLS fallback, monitor certificate issuance, inventory every hostname, test routing, and enforce access inside the application. That gives visitors the privacy improvement without letting a quieter handshake create louder assumptions about secrecy, security, or availability.