Envoy: Behavior filter_chain's application_protocols when the listener has both tls_inspector and http_inspector filters

[shashankram]

Description:
As per the documentation in https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/http_inspector and https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/tls_inspector, it seems like both the tls_inspecter and http_inspector listener filters set the application_protocols field that a filter chain can match on.

Per my understanding, the tls_inspector sets this based on the ALPN set by the client during the TLS handshake, while the http_inspector sets this to either http/1.x or http/2.

So if a listener has both the tls_inspector and http_inspector listener filters, what is the expected behavior of the value set for the application_protocols to be used in the filter_chain_match?

The documentation https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/listener/v3/listener_components.proto#envoy-v3-api-field-config-listener-v3-filterchainmatch-application-protocols isn't too clear either because it doesn't describe how http_inspector filter updates this field.

For my use case, I want to be able to reliably differentiate between HTTP vs TCP traffic on the same listener via filter chain matching, irrespective of the ALPN set by clients.

[optional Relevant Links:]

Any extra documentation required to understand the issue.
Updating https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/listener/v3/listener_components.proto#envoy-v3-api-field-config-listener-v3-filterchainmatch-application-protocols to describe how http_inspector affects it will be helpful.

[lambdai]

EDIT: servername -> alpn
http inspector is skipped when tls_inspector sniff out the traffic is TLS. The reason is that http inspector cannot really inspect TLS traffic.

If it is TLS traffic both alpn and transport socket name is set while http inspector wont set transport socket name

[shashankram]

http inspector is skipped when tls_inspector sniff out the traffic is TLS. The reason is that http inspector cannot really inspect TLS traffic.

If it is TLS traffic both servername and transport socket name is set while http inspector wont set transport socket name

Thanks @lambdai. What are the allowed values for application_protocols that http_inspector can set (ex. [http/1.0, http/1.1, http/2, h2c ..])?

[lambdai]

http inspect has very limited value space, you can find it in the code.
For tls inspector, the value space is way much wider. I don't know if there is an allowlist
https://tools.ietf.org/html/rfc7301

[shashankram]

EDIT: servername -> alpn
http inspector is skipped when tls_inspector sniff out the traffic is TLS. The reason is that http inspector cannot really inspect TLS traffic.

If it is TLS traffic both alpn and transport socket name is set while http inspector wont set transport socket name

Per the docs the http_inspector only sets application_protocol and not the transport socket. Is that correct?
What are the allowed values for application_protocol that http_inspector can set? From the code it looks like one of [http/1.0, http/1.1, h2, h2c].

[shashankram]

EDIT: servername -> alpn
http inspector is skipped when tls_inspector sniff out the traffic is TLS. The reason is that http inspector cannot really inspect TLS traffic.
If it is TLS traffic both alpn and transport socket name is set while http inspector wont set transport socket name

Per the docs the http_inspector only sets application_protocol and not the transport socket. Is that correct?
What are the allowed values for application_protocol that http_inspector can set? From the code it looks like one of [http/1.0, http/1.1, h2, h2c].

Ok I found the values here: https://github.com/envoyproxy/envoy/blob/da403fa7b67b9331ca1d129a4035950d2e23c752/source/common/http/utility.h#L37

[shashankram]

@lambdai, on the inbound filter chain is there a way to distinguish between HTTP TLS vs TCP TLS traffic?
Since the TLS traffic is decrypted based on the DownstreamTlsContextspecified in the filter chain, I am not sure if there is a way to even distinguish between TCP vs HTTP when the incoming traffic is TLS encrypted.

[lambdai]

Since the TLS traffic is decrypted based on the DownstreamTlsContextspecified in the filter chain, I am not sure if there is a way to even distinguish between TCP vs HTTP when the incoming traffic is TLS encrypted.

The inspection happens before a network filter chain is selected. The major goal of inspector is to determine the network filter chain.
Since DownstreamTlsContext is provided in filter chain which is after the inspection, there is no tls context for the inspectors.

[shashankram]

Since the TLS traffic is decrypted based on the DownstreamTlsContextspecified in the filter chain, I am not sure if there is a way to even distinguish between TCP vs HTTP when the incoming traffic is TLS encrypted.

The inspection happens before a network filter chain is selected. The major goal of inspector is to determine the network filter chain.
Since DownstreamTlsContext is provided in filter chain which is _after_ the inspection, there is no tls context for the inspectors.

Got it, thank you.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.