Empty command operator DOWNSTREAM_TLS_SESSION_ID (for including X-SSL-SESSION-ID header)

[V1cenZ]

Description:

When using Envoy Gateway with Gateway API, most substitution format operators work as expected when setting request headers via ClientTrafficPolicy. However, the %DOWNSTREAM_TLS_SESSION_ID% operator always resolves to an empty value.

This happens even when TLS session resumption is explicitly enabled with session-id or session-tickets.

session:
  resumption:
    stateless: {} (also tested with statefull mode)

DOWNSTREAM_TLS_SESSION_ID is included in the command operators that should be supported:

https://www.envoyproxy.io/docs/envoy/latest/configuration/advanced/substitution_formatter#config-advanced-substitution-operators

Repro steps:

The issue occurs with the following ClientTrafficPolicy:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: ClientTrafficPolicy
metadata:
  name: client-traffic-policy
  namespace: envoy-gateway-system
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: eg
    sectionName: https-443
    session:
      resumption:
        stateless: {}
  headers:
    earlyRequestHeaders:
      set:
      - name: "X-Client-IP"
        value: "%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%"
      - name: "X-Real-IP"
        value: "%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%"
      - name: "X-Original-Forwarded-For"
        value: "%REQ(X-Forwarded-For)%"
      - name: "X-SSL-PROTOCOL"
        value: "%DOWNSTREAM_TLS_VERSION%"
      - name: "X-SSL-CIPHER"
        value: "%DOWNSTREAM_TLS_CIPHER%"
      - name: "X-SSL-SESSION-ID"
        value: "test-%DOWNSTREAM_TLS_SESSION_ID%-end"


*Environment*:
 
Using 1.7.0 envoy Gateway version.

*Logs*:

X-SSL-Protocol and X-SSL-Cipher are correctly received by the backend, but X-SSL-Session-ID is not.

X-SSL-Protocol: TLSv1.3
X-SSL-Cipher: TLS_AES_256_GCM_SHA384
X-SSL-Session-ID: test--end

[wbpcode]

session ID is an implementation detail of the TLS resumption handshake mechanism. Not all resumption flows use session IDs, and not all connections within an application-level session will reuse TLS sessions.

[V1cenZ]

Hi @wbpcode, thank you for your response!.

I understand that there are two mechanisms to resume a TLS session: session tickets and session IDs.

In any case, the tests I have performed were from the same origin, making the same request to the same backend, first accessing it through an NGINX Ingress and then through my Envoy Gateway. And the only difference between both is that Envoy does not include the session ID value, taking it from %DOWNSTREAM_TLS_SESSION_ID% envoy command operator.

I conducted the tests using a single Envoy pod (since in Envoy Gateway, sessions are only resumed if the request from the same client reaches the same pod, as keys are not shared between pods). I tested both with:

session:
resumption:
stateful: {} (uses session ID)

and with:

session:
resumption:
stateless: {} (uses session tickets)

[wbpcode]

Hello, cc @V1cenZ , sorry I didn't get you clearly? I don't clear to the implementation detail of EG's stateful/stateless, but I guess this actual also affected by the client?
After the negotiation of TLS version, may be your expected behavior never happens?

And if possible, could you share a Envoy config dump here? Thanks.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.