TLS transport socket¶

This extension may be referenced by the qualified name envoy.transport_sockets.tls

Note

This extension is intended to be robust against both untrusted downstream and upstream traffic.

The TLS contexts below provide the transport socket configuration for upstream/downstream TLS.

extensions.transport_sockets.tls.v3.UpstreamTlsContext¶

[extensions.transport_sockets.tls.v3.UpstreamTlsContext proto]

{
  "common_tls_context": "{...}",
  "sni": "...",
  "allow_renegotiation": "...",
  "max_session_keys": "{...}"
}

common_tls_context: (extensions.transport_sockets.tls.v3.CommonTlsContext) Common TLS context settings.

Attention

Server certificate verification is not enabled by default. Configure trusted_ca to enable verification.

sni: (string) SNI string to use when creating TLS backend connections.

allow_renegotiation: (bool) If true, server-initiated TLS renegotiation will be allowed.

Attention

TLS renegotiation is considered insecure and shouldn’t be used unless absolutely necessary.

max_session_keys

(UInt32Value) Maximum number of session keys (Pre-Shared Keys for TLSv1.3+, Session IDs and Session Tickets for TLSv1.2 and older) to store for the purpose of session resumption.

Defaults to 1, setting this to 0 disables session resumption.

extensions.transport_sockets.tls.v3.DownstreamTlsContext¶

[extensions.transport_sockets.tls.v3.DownstreamTlsContext proto]

{
  "common_tls_context": "{...}",
  "require_client_certificate": "{...}",
  "session_ticket_keys": "{...}",
  "session_ticket_keys_sds_secret_config": "{...}",
  "disable_stateless_session_resumption": "...",
  "session_timeout": "{...}",
  "ocsp_staple_policy": "..."
}

common_tls_context: (extensions.transport_sockets.tls.v3.CommonTlsContext) Common TLS context settings.

require_client_certificate: (BoolValue) If specified, Envoy will reject connections without a valid client certificate.

session_ticket_keys

(extensions.transport_sockets.tls.v3.TlsSessionTicketKeys) TLS session ticket key settings.

Only one of session_ticket_keys, session_ticket_keys_sds_secret_config, disable_stateless_session_resumption may be set.

session_ticket_keys_sds_secret_config

(extensions.transport_sockets.tls.v3.SdsSecretConfig) Config for fetching TLS session ticket keys via SDS API.

Only one of session_ticket_keys, session_ticket_keys_sds_secret_config, disable_stateless_session_resumption may be set.

disable_stateless_session_resumption

(bool) Config for controlling stateless TLS session resumption: setting this to true will cause the TLS server to not issue TLS session tickets for the purposes of stateless TLS session resumption. If set to false, the TLS server will issue TLS session tickets and encrypt/decrypt them using the keys specified through either session_ticket_keys or session_ticket_keys_sds_secret_config. If this config is set to false and no keys are explicitly configured, the TLS server will issue TLS session tickets and encrypt/decrypt them using an internally-generated and managed key, with the implication that sessions cannot be resumed across hot restarts or on different hosts.

Only one of session_ticket_keys, session_ticket_keys_sds_secret_config, disable_stateless_session_resumption may be set.

session_timeout: (Duration) If specified, session_timeout will change maximum lifetime (in seconds) of TLS session Currently this value is used as a hint to TLS session ticket lifetime (for TLSv1.2) <https://tools.ietf.org/html/rfc5077#section-5.6> only seconds could be specified (fractional seconds are going to be ignored).

ocsp_staple_policy: (extensions.transport_sockets.tls.v3.DownstreamTlsContext.OcspStaplePolicy) Config for whether to use certificates if they do not have an accompanying OCSP response or if the response expires at runtime. Defaults to LENIENT_STAPLING

Enum extensions.transport_sockets.tls.v3.DownstreamTlsContext.OcspStaplePolicy¶

[extensions.transport_sockets.tls.v3.DownstreamTlsContext.OcspStaplePolicy proto]

LENIENT_STAPLING: (DEFAULT) ⁣OCSP responses are optional. If an OCSP response is absent or expired, the associated certificate will be used for connections without an OCSP staple.

STRICT_STAPLING: ⁣OCSP responses are optional. If an OCSP response is absent, the associated certificate will be used without an OCSP staple. If a response is provided but is expired, the associated certificate will not be used for subsequent connections. If no suitable certificate is found, the connection is rejected.

MUST_STAPLE: ⁣OCSP responses are required. Configuration will fail if a certificate is provided without an OCSP response. If a response expires, the associated certificate will not be used connections. If no suitable certificate is found, the connection is rejected.

extensions.transport_sockets.tls.v3.CommonTlsContext¶

[extensions.transport_sockets.tls.v3.CommonTlsContext proto]

TLS context shared by both client and server TLS contexts.

{
  "tls_params": "{...}",
  "tls_certificates": [],
  "tls_certificate_sds_secret_configs": [],
  "validation_context": "{...}",
  "validation_context_sds_secret_config": "{...}",
  "combined_validation_context": "{...}",
  "alpn_protocols": [],
  "custom_handshaker": "{...}"
}

tls_params: (extensions.transport_sockets.tls.v3.TlsParameters) TLS protocol versions, cipher suites etc.

tls_certificates

(extensions.transport_sockets.tls.v3.TlsCertificate) Multiple TLS certificates can be associated with the same context to allow both RSA and ECDSA certificates.

Only a single TLS certificate is supported in client contexts. In server contexts, the first RSA certificate is used for clients that only support RSA and the first ECDSA certificate is used for clients that support ECDSA.

tls_certificate_sds_secret_configs: (extensions.transport_sockets.tls.v3.SdsSecretConfig) Configs for fetching TLS certificates via SDS API. Note SDS API allows certificates to be fetched/refreshed over the network asynchronously with respect to the TLS handshake.

validation_context

(extensions.transport_sockets.tls.v3.CertificateValidationContext) How to validate peer certificates.

Only one of validation_context, validation_context_sds_secret_config, combined_validation_context may be set.

validation_context_sds_secret_config

(extensions.transport_sockets.tls.v3.SdsSecretConfig) Config for fetching validation context via SDS API. Note SDS API allows certificates to be fetched/refreshed over the network asynchronously with respect to the TLS handshake.

Only one of validation_context, validation_context_sds_secret_config, combined_validation_context may be set.

combined_validation_context

(extensions.transport_sockets.tls.v3.CommonTlsContext.CombinedCertificateValidationContext) Combined certificate validation context holds a default CertificateValidationContext and SDS config. When SDS server returns dynamic CertificateValidationContext, both dynamic and default CertificateValidationContext are merged into a new CertificateValidationContext for validation. This merge is done by Message::MergeFrom(), so dynamic CertificateValidationContext overwrites singular fields in default CertificateValidationContext, and concatenates repeated fields to default CertificateValidationContext, and logical OR is applied to boolean fields.

Only one of validation_context, validation_context_sds_secret_config, combined_validation_context may be set.

alpn_protocols

(string) Supplies the list of ALPN protocols that the listener should expose. In practice this is likely to be set to one of two values (see the codec_type parameter in the HTTP connection manager for more information):

“h2,http/1.1” If the listener is going to support both HTTP/2 and HTTP/1.1.
“http/1.1” If the listener is only going to support HTTP/1.1.

There is no default for this parameter. If empty, Envoy will not expose ALPN.

custom_handshaker: (config.core.v3.TypedExtensionConfig) Custom TLS handshaker. If empty, defaults to native TLS handshaking behavior.

extensions.transport_sockets.tls.v3.CommonTlsContext.CertificateProvider¶

[extensions.transport_sockets.tls.v3.CommonTlsContext.CertificateProvider proto]

Config for Certificate provider to get certificates. This provider should allow certificates to be fetched/refreshed over the network asynchronously with respect to the TLS handshake.

{
  "name": "...",
  "typed_config": "{...}"
}

name: (string, REQUIRED) opaque name used to specify certificate instances or types. For example, “ROOTCA” to specify a root-certificate (validation context) or “TLS” to specify a new tls-certificate.

typed_config: (config.core.v3.TypedExtensionConfig, REQUIRED) Provider specific config. Note: an implementation is expected to dedup multiple instances of the same config to maintain a single certificate-provider instance. The sharing can happen, for example, among multiple clusters or between the tls_certificate and validation_context certificate providers of a cluster. This config could be supplied inline or (in future) a named xDS resource.

extensions.transport_sockets.tls.v3.CommonTlsContext.CertificateProviderInstance¶

[extensions.transport_sockets.tls.v3.CommonTlsContext.CertificateProviderInstance proto]

Similar to CertificateProvider above, but allows the provider instances to be configured on the client side instead of being sent from the control plane.

{
  "instance_name": "...",
  "certificate_name": "..."
}

instance_name

(string) Provider instance name. This name must be defined in the client’s configuration (e.g., a bootstrap file) to correspond to a provider instance (i.e., the same data in the typed_config field that would be sent in the CertificateProvider message if the config was sent by the control plane). If not present, defaults to “default”.

Instance names should generally be defined not in terms of the underlying provider implementation (e.g., “file_watcher”) but rather in terms of the function of the certificates (e.g., “foo_deployment_identity”).

certificate_name: (string) Opaque name used to specify certificate instances or types. For example, “ROOTCA” to specify a root-certificate (validation context) or “example.com” to specify a certificate for a particular domain. Not all provider instances will actually use this field, so the value defaults to the empty string.

extensions.transport_sockets.tls.v3.CommonTlsContext.CombinedCertificateValidationContext¶

[extensions.transport_sockets.tls.v3.CommonTlsContext.CombinedCertificateValidationContext proto]

{
  "default_validation_context": "{...}",
  "validation_context_sds_secret_config": "{...}"
}

default_validation_context: (extensions.transport_sockets.tls.v3.CertificateValidationContext, REQUIRED) How to validate peer certificates.

validation_context_sds_secret_config: (extensions.transport_sockets.tls.v3.SdsSecretConfig, REQUIRED) Config for fetching validation context via SDS API. Note SDS API allows certificates to be fetched/refreshed over the network asynchronously with respect to the TLS handshake. Only one of validation_context_sds_secret_config, validation_context_certificate_provider, or validation_context_certificate_provider_instance may be used.