TLS

    • Configurable ciphers: Each TLS listener and client can specify the ciphers that it supports.
    • Certificate verification and pinning: Certificate verification options include basic chain verification, subject name verification, and hash pinning.
    • Certificate revocation: Envoy can check peer certificates against a certificate revocation list (CRL) if one is provided.
    • ALPN: TLS listeners support ALPN. The HTTP connection manager uses this information (in addition to protocol inference) to determine whether a client is speaking HTTP/1.1 or HTTP/2.
    • SNI: SNI is supported for both server (listener) and client (upstream) connections.
    • Session resumption: Server connections support resuming previous sessions via TLS session tickets (see ). Resumption can be performed across hot restarts and between parallel Envoy instances (typically useful in a front proxy configuration).

    Currently Envoy is written to use BoringSSL as the TLS provider.

    FIPS 140-2

    BoringSSL can be built in a FIPS-compliant mode, following the build instructions from the , using Bazel option. Currently, this option is only available on Linux-x86_64.

    The correctness of the FIPS build can be verified by checking the presence of in the output.

    Please note that the FIPS-compliant build is based on an older version of BoringSSL than the non-FIPS build, and it predates the final version of TLS 1.3.

    Certificate verification of both upstream and downstream connections is not enabled unless the validation context specifies one or more trusted authority certificates.

    /etc/ssl/certs/ca-certificates.crt is the default path for the system CA bundle on Debian systems. This makes Envoy verify the server identity of 127.0.0.2:1234 in the same way as e.g. cURL does on standard Debian installations. Common paths for system CA bundles on Linux and BSD are

    • /etc/ssl/certs/ca-certificates.crt (Debian/Ubuntu/Gentoo etc.)
    • /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (CentOS/RHEL 7)
    • /etc/pki/tls/certs/ca-bundle.crt (Fedora/RHEL 6)
    • /usr/local/etc/ssl/cert.pem (FreeBSD)
    • /etc/ssl/cert.pem (OpenBSD)

    Certificate selection

    DownstreamTlsContexts support multiple TLS certificates. These may be a mix of RSA and P-256 ECDSA certificates. The following rules apply:

    • Only one certificate of a particular type (RSA or ECDSA) may be specified.
    • Non-P-256 server ECDSA certificates are rejected.
    • If the client supports P-256 ECDSA, a P-256 ECDSA certificate will be selected if present in the .
    • If the client only supports RSA certificates, a RSA certificate will be selected if present in the DownstreamTlsContext.
    • Otherwise, the first certificate listed is used. This will result in a failed handshake if the client only supports RSA certificates and the server only has ECDSA certificates.
    • Static and SDS certificates may not be mixed in a given .

    Only a single TLS certificate is supported today for UpstreamTlsContexts.

    TLS certificates can be specified in the static resource or can be fetched remotely. Please see for details.

    Authentication filter

    Client TLS authentication filter .