Consider aligning how SNI is set for upstream TLS

[tsaarni]

Currently Contour uses SNI for upstream TLS connection in following ways:

• httpproxy: SNI is not set by default. It is set if (1) user defines requestHeadersPolicy with key Host or if (2) the referred Service is of type ExternalName and external name services are enabled (see logic here).
• tcpproxy: SNI is not set (see issue #4373).
• extensionservice: SNI is set if validation is enabled. Value is set from extensionservice.spec.validation.subjectName, or subjectNames[0] in the next release.
• ingress: SNI or upstream validation is not supported (see code).
• Gateway API: (1) HTTPRoute supports upstream TLS (it sets Cluster.Protocol) but does not support SNI or validation (it does not set Cluster.[SNI|UpstreamValidation]), (2) TLSRoute does not seem to support upstream TLS, but still sets Cluster.SNI which has no effect without upstream TLS, (3) GRPCRoute supports upstream TLS but does not support SNI or validation, (4) TCPRoute does not seem to support upstream TLS but still sets SNI field.

It would be nice if SNI was set by default, and if the default behaviour was aligned between all above cases (this does not imply removing current behaviour).

One alternative could be to use the subjectAltName from validation in all cases, that is, align the defaults with current extensionservice behaviour. Sometimes the validation context is omitted and SNI would not get set.

Usually SNI is set to the hostname that the client is connecting to, that is, if service name is 'foo', then SNI is set to foo. This is the behaviour that all TLS client applications usually implement, and is expected by RFC6066

"HostName" contains the fully qualified DNS hostname of the server, as understood by the client.

This also aligns with current ExternalName behaviour.

One option could be to use subject alternative name from validation.subjectName when present, but fall back to service hostname when it is not configured and for resource types that do not support it.

[skriss]

xref https://github.com/projectcontour/contour/issues/2893

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack