fix: match SNI when using TLS listeners with hostname

[michaelbeaumont]

What type of PR is this?

A fix for TLS listener with hostname handling.

What this PR does / why we need it:

This PR sets filterChainMatch.serverNames when using TLS listeners with a hostname.

Which issue(s) this PR fixes:

[arkodg]

hey @michaelbeaumont, for my understanding, is this PR is trying to solve ?

Listener Protocol: TLS
TLS Mode: Terminate
Route Type: TCPRoute

https://gateway-api.sigs.k8s.io/guides/tls/#clientserver-and-tls

afaik this should be supported today https://github.com/envoyproxy/gateway/pull/1431 https://gateway.envoyproxy.io/v1.0.0/user/security/tls-termination/

[michaelbeaumont]

Hey, yeah traffic is terminated properly, but if I set hostname on that listener, there's no filtering of traffic by SNI as specified by the spec for hostname. The final commit shows the difference for this listener.

Implementations MUST apply Hostname matching appropriately for each of the following protocols:

• TLS: The Listener Hostname MUST match the SNI.

[arkodg]

got it makes sense, thanks for clarifying ! is there a way to modify the TCP Listener IR w/o affecting the HTTP Listener IR structure and achieving the same goal ? Currently the Hostnames field within the HTTP Listener is used for Filter Chain creation with a server_name constaint

[shuji-2019]

Is there any updates for this feature ?

[aoledk]

@michaelbeaumont Are you still working on this? If not I can help, based on your previous work.

[michaelbeaumont]

Updated and merged

[arkodg]

@michaelbeaumont 'make lint's is failing because of trailing whitespaces, once that's fixed, LGTM from my end !

[arkodg]

@michaelbeaumont can you also fix DCO and force push ?

[michaelbeaumont]

@zhaohuabing I added another SNI to the test https://github.com/envoyproxy/gateway/pull/2942/files#diff-3481ca7cb1d20b614db1882fa576de2d303d434e519a17d12c2792436d6a0e18R28 actually