TLS ALPN

Force HTTP 1.1

https://www.tetrate.io/blog/envoy-and-istio-security-releases-june-2020/

Envoy versions can mitigate those vulnerabilities by disabling HTTP2 and allowing only HTTP/1.1 by setting http_connection_manager.codec_type to “HTTP1” and removing “h2” from common_tls_context.alpn_protocols.

For Istio:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: disable-ingress-h2
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: NETWORK_FILTER # http connection manager is a filter in Envoy
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.http_connection_manager"
    patch:
      operation: MERGE
      value:
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          codec_type: HTTP1

HTTP 1.1 Upgrade header

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/http/upgrades#http-upgrades

Envoy Upgrade support is intended mainly for WebSocket and CONNECT support, but may be used for arbitrary upgrades as well. Upgrades pass both the HTTP headers and the upgrade payload through an HTTP filter chain. One may configure the upgrade_configs with or without custom filter chains. If only the upgrade_type is specified, both the upgrade headers, any request and response body, and HTTP data payload will pass through the default HTTP filter chain. To avoid the use of HTTP-only filters for upgrade payload, one can set up custom filters for the given upgrade type, up to and including only using the router filter to send the HTTP data upstream. Note that buffering is generally not compatible with upgrades, so if the Buffer filter is configured in the default HTTP filter chain it should probably be excluded for upgrades by using upgrade filters and not including the buffer filter in that list.

Upgrades can be enabled or disabled on a per-route basis. Any per-route enabling/disabling automatically overrides HttpConnectionManager configuration as laid out below, but custom filter chains can only be configured on a per-HttpConnectionManager basis.

Note that the statistics for upgrades are all bundled together so WebSocket and other upgrades statistics are tracked by stats such as downstream_cx_upgrades_total and downstream_cx_upgrades_active

https://www.dazhuanlan.com/ischool/topics/1587694 :

在 http_connection_mananger 中加 upgrade_configs 配置

https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto.html?highlight=upgrade_configs#extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-upgradeconfig

[extensions.filters.network.http_connection_manager.v3.HttpConnectionManager proto]

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

{
  "codec_type": "...",
  "stat_prefix": "...",
  "rds": "{...}",
  "route_config": "{...}",
  "scoped_routes": "{...}",
  "http_filters": [],
  "add_user_agent": "{...}",
  "tracing": "{...}",
  "common_http_protocol_options": "{...}",
  "http_protocol_options": "{...}",
  "http2_protocol_options": "{...}",
  "server_name": "...",
  "server_header_transformation": "...",
  "scheme_header_transformation": "{...}",
  "max_request_headers_kb": "{...}",
  "stream_idle_timeout": "{...}",
  "request_timeout": "{...}",
  "request_headers_timeout": "{...}",
  "drain_timeout": "{...}",
  "delayed_close_timeout": "{...}",
  "access_log": [],
  "use_remote_address": "{...}",
  "xff_num_trusted_hops": "...",
  "original_ip_detection_extensions": [],
  "internal_address_config": "{...}",
  "skip_xff_append": "...",
  "via": "...",
  "generate_request_id": "{...}",
  "preserve_external_request_id": "...",
  "always_set_request_id_in_response": "...",
  "forward_client_cert_details": "...",
  "set_current_client_cert_details": "{...}",
  "proxy_100_continue": "...",
  "upgrade_configs": [],
  "normalize_path": "{...}",
  "merge_slashes": "...",
  "path_with_escaped_slashes_action": "...",
  "request_id_extension": "{...}",
  "local_reply_config": "{...}",
  "strip_matching_host_port": "...",
  "strip_any_host_port": "...",
  "stream_error_on_invalid_http_message": "{...}",
  "strip_trailing_host_dot": "..."
}

upgrade_configs:

(repeated extensions.filters.network.http_connection_manager.v3.HttpConnectionManager.UpgradeConfig)

extensions.filters.network.http_connection_manager.v3.HttpConnectionManager.UpgradeConfig:

The configuration for HTTP upgrades. For each upgrade type desired, an UpgradeConfig must be added.

Warning
The current implementation of upgrade headers does not handle multi-valued upgrade > headers. Support for multi-valued headers may be added in the future if needed.

Warning
The current implementation of upgrade headers does not work with HTTP/2 upstreams.

1
2
3
4
5

{
  "upgrade_type": "...",
  "filters": [],
  "enabled": "{...}"
}

• upgrade_type

  (string) The case-insensitive name of this upgrade, e.g. “websocket”. For each upgrade type present in upgrade_configs, requests with Upgrade: [upgrade_type] will be proxied upstream.

• filters

  (repeated extensions.filters.network.http_connection_manager.v3.HttpFilter) If present, this represents the filter chain which will be created for this type of upgrade. If no filters are present, the filter chain for HTTP connections will be used for this upgrade type.

enabled

(BoolValue) Determines if upgrades are enabled or disabled by default. Defaults to true. This can be overridden on a per-route basis with cluster as documented in the upgrade documentation.

Ref
https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto.html?highlight=upgrade_configs#extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-upgradeconfig
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/http/upgrades#http-upgrades

Google Cloud

https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-http2
An HTTP(S) load balancer acts as a proxy between your clients and your application. Clients can use HTTP/1.1 or HTTP/2 to communicate with the load balancer proxy. However, the connection from the load balancer proxy to your application uses HTTP/1.1 by default. If your application, running in a Google Kubernetes Engine pod, is capable of receiving HTTP/2 requests, you configure the external load balancer to use HTTP/2 when it forwards requests to your application.