Skip to content

Feature request: server-side option to require ECH (reject non-ECH clients) #10082

@cpsource

Description

@cpsource

Version

5.9.0

Description

When a server is configured with ECH keys via wolfSSL_CTX_GenerateEchConfig(), there is no option to reject clients that do not use ECH. The server always falls back to the outer ClientHello when ECH is absent or decryption fails.

The draft-ietf-tls-esni-18 spec places enforcement on the client side (ech_required alert), assuming a CDN/proxy deployment model. In direct server deployments where the operator controls both ends, server-side enforcement is needed to prevent downgrade attacks where an attacker strips or modifies the ECH extension to expose the real SNI.

Requested feature

A server-side API to require ECH:

wolfSSL_CTX_SetEchRequired(ctx, 1);

When enabled, the server would abort the handshake (e.g., illegal_parameter) if:

  • The ClientHello has no ECH extension
  • ECH decryption fails (tampered or stripped extension)

This would prevent man-in-the-middle attacks that strip ECH to force a plaintext SNI fallback.

Current behavior

  • Server receives ClientHello without ECH → proceeds normally with outer hello
  • Server receives ClientHello with ECH that fails to decrypt → falls back to outer hello and sends retry_configs
  • No way to enforce that ECH was successfully used

Use case

Direct server deployments (not CDN/proxy) where the operator wants to guarantee that all clients use ECH, and any connection without it should be rejected.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions