diff --git a/docs/_static/double_proxy.svg b/docs/_static/double_proxy.svg index 7c1ac6365b3a..60a9cfcade0f 100644 --- a/docs/_static/double_proxy.svg +++ b/docs/_static/double_proxy.svg @@ -1,4 +1,4 @@ - + diff --git a/docs/_static/front_proxy.svg b/docs/_static/front_proxy.svg index a5cc53a4ed4a..97c2a325232a 100644 --- a/docs/_static/front_proxy.svg +++ b/docs/_static/front_proxy.svg @@ -1,4 +1,4 @@ - + diff --git a/docs/configuration/cluster_manager/cluster.rst b/docs/configuration/cluster_manager/cluster.rst index 6415cd84f4e9..43310405b98f 100644 --- a/docs/configuration/cluster_manager/cluster.rst +++ b/docs/configuration/cluster_manager/cluster.rst @@ -116,8 +116,8 @@ max_retries ` for more information. :ref:`ssl_context ` - *(optional, object)* The SSL configuration for connections to the upstream cluster. If no SSL - configuration is specified, SSL will not be used for new connections. + *(optional, object)* The TLS configuration for connections to the upstream cluster. If no TLS + configuration is specified, TLS will not be used for new connections. .. _config_cluster_manager_cluster_features: @@ -128,7 +128,7 @@ features http2 If *http2* is specified, Envoy will assume that the upstream supports HTTP/2 when making new HTTP connection pool connections. Currently, Envoy only supports prior knowledge for upstream - connections. Even if SSL is used with ALPN, *http2* must be specified. As an aside this allows + connections. Even if TLS is used with ALPN, *http2* must be specified. As an aside this allows HTTP/2 connections to happen over plain text. .. _config_cluster_manager_cluster_http_codec_options: diff --git a/docs/configuration/cluster_manager/cluster_ssl.rst b/docs/configuration/cluster_manager/cluster_ssl.rst index 08a146718fd4..475d27b05e4f 100644 --- a/docs/configuration/cluster_manager/cluster_ssl.rst +++ b/docs/configuration/cluster_manager/cluster_ssl.rst @@ -1,6 +1,6 @@ .. _config_cluster_manager_cluster_ssl: -SSL context +TLS context =========== .. code-block:: json @@ -27,7 +27,7 @@ alpn_protocols cert_chain_file *(optional, string)* The certificate chain file that should be served by the connection. This is - used to provide a client side SSL certificate to an upstream host. + used to provide a client side TLS certificate to an upstream host. private_key_file *(optional, string)* The private key that corresponds to the certificate chain file. @@ -45,9 +45,9 @@ verify_subject_alt_name name matches the specified value. cipher_suites - *(optional, string)* If specified, the SSL connection will only support the specified cipher list. + *(optional, string)* If specified, the TLS connection will only support the specified cipher list. If not specified, a default list will be used. sni - *(optional, string)* If specified, the string will be presented as the SNI during the SSL + *(optional, string)* If specified, the string will be presented as the SNI during the TLS handshake. diff --git a/docs/configuration/http_conn_man/headers.rst b/docs/configuration/http_conn_man/headers.rst index e0ed70f5a333..b13c98efb48c 100644 --- a/docs/configuration/http_conn_man/headers.rst +++ b/docs/configuration/http_conn_man/headers.rst @@ -47,7 +47,7 @@ Internal services often want to know which service is calling them. This header external requests, but for internal requests will contain the service cluster of the caller. Note that in the current implementation, this should be considered a hint as it is set by the caller and could be easily spoofed by any internal entity. In the future Envoy will support a mutual -authentication SSL mesh which will make this header fully secure. Like *user-agent*, the value +authentication TLS mesh which will make this header fully secure. Like *user-agent*, the value is determined by the :option:`--service-cluster` command line option. .. _config_http_conn_man_headers_x-envoy-external-address: diff --git a/docs/configuration/http_conn_man/http_conn_man.rst b/docs/configuration/http_conn_man/http_conn_man.rst index 11f6b481db90..5ae115a5dcd1 100644 --- a/docs/configuration/http_conn_man/http_conn_man.rst +++ b/docs/configuration/http_conn_man/http_conn_man.rst @@ -37,11 +37,11 @@ codec_type http2 The connection manager will assume that the client is speaking HTTP/2 (Envoy does not require - HTTP/2 to take place over SSL or to use ALPN. Prior knowledge is allowed). + HTTP/2 to take place over TLS or to use ALPN. Prior knowledge is allowed). auto For every new connection, the connection manager will determine which codec to use. This mode - supports both ALPN for SSL listeners as well as protocol inference for plaintext listeners. + supports both ALPN for TLS listeners as well as protocol inference for plaintext listeners. If ALPN data is available, it is preferred, otherwise protocol inference is used. In almost all cases, this is the right option to choose for this setting. diff --git a/docs/configuration/http_conn_man/route_config/vhost.rst b/docs/configuration/http_conn_man/route_config/vhost.rst index f4605f5b281c..275298889748 100644 --- a/docs/configuration/http_conn_man/route_config/vhost.rst +++ b/docs/configuration/http_conn_man/route_config/vhost.rst @@ -34,18 +34,18 @@ domains The first route that matches will be used. require_ssl - *(optional, string)* Specifies the type of SSL enforcement the virtual host expects. Possible + *(optional, string)* Specifies the type of TLS enforcement the virtual host expects. Possible values are: all - All requests must use SSL. If a request is not using SSL, a 302 redirect will be sent telling + All requests must use TLS. If a request is not using TLS, a 302 redirect will be sent telling the client to use HTTPS. external_only - External requests must use SSL. If a request is external and it is not using SSL, a 302 redirect + External requests must use TLS. If a request is external and it is not using TLS, a 302 redirect will be sent telling the client to use HTTPS. - If this option is not specified, there is no SSL requirement for the virtual host. + If this option is not specified, there is no TLS requirement for the virtual host. :ref:`virtual_clusters ` *(optional, array)* A list of virtual clusters defined for this virtual host. Virtual clusters diff --git a/docs/configuration/http_conn_man/stats.rst b/docs/configuration/http_conn_man/stats.rst index 5a6b973085b1..2395d2ce349d 100644 --- a/docs/configuration/http_conn_man/stats.rst +++ b/docs/configuration/http_conn_man/stats.rst @@ -11,7 +11,7 @@ statistics: :widths: 1, 1, 2 downstream_cx_total, Counter, Total connections - downstream_cx_ssl_total, Counter, Total SSL connections + downstream_cx_ssl_total, Counter, Total TLS connections downstream_cx_http1_total, Counter, Total HTTP/1.1 connections downstream_cx_http2_total, Counter, Total HTTP/2 connections downstream_cx_destroy, Counter, Total connections destroyed @@ -21,7 +21,7 @@ statistics: downstream_cx_destroy_local_active_rq, Counter, Total connections destroyed locally with 1+ active request downstream_cx_destroy_remote_active_rq, Counter, Total connections destroyed remotely with 1+ active request downstream_cx_active, Gauge, Total active connections - downstream_cx_ssl_active, Gauge, Total active SSL connections + downstream_cx_ssl_active, Gauge, Total active TLS connections downstream_cx_http1_active, Gauge, Total active HTTP/1.1 connections downstream_cx_http2_active, Gauge, Total active HTTP/2 connections downstream_cx_protocol_error, Counter, Total protocol errors diff --git a/docs/configuration/listeners/listeners.rst b/docs/configuration/listeners/listeners.rst index ead7a1f1fe0b..fa68bbfe29ec 100644 --- a/docs/configuration/listeners/listeners.rst +++ b/docs/configuration/listeners/listeners.rst @@ -25,8 +25,8 @@ port filters are processed sequentially as connection events happen. :ref:`ssl_context ` - *(optional, object)* The :ref:`SSL ` context configuration for an SSL listener. - If no SSL context block is defined, the listener is a plain text listener. + *(optional, object)* The :ref:`TLS ` context configuration for a TLS listener. + If no TLS context block is defined, the listener is a plain text listener. use_proxy_proto *(optional, boolean)* Whether the listener should expect a diff --git a/docs/configuration/listeners/ssl.rst b/docs/configuration/listeners/ssl.rst index 7aaad0094949..3605c690523f 100644 --- a/docs/configuration/listeners/ssl.rst +++ b/docs/configuration/listeners/ssl.rst @@ -1,9 +1,9 @@ .. _config_listener_ssl_context: -SSL context +TLS context =========== -SSL :ref:`architecture overview `. +TLS :ref:`architecture overview `. .. code-block:: json @@ -53,5 +53,5 @@ verify_subject_alt_name name matches the specified value. cipher_suites - *(optional, string)* If specified, the SSL listener will only support the specified cipher list. + *(optional, string)* If specified, the TLS listener will only support the specified cipher list. If not specified, a default list will be used. diff --git a/docs/configuration/listeners/stats.rst b/docs/configuration/listeners/stats.rst index efa97411762f..9e51ce817b41 100644 --- a/docs/configuration/listeners/stats.rst +++ b/docs/configuration/listeners/stats.rst @@ -13,9 +13,9 @@ Every listener has a statistics tree rooted at *listener..* with the follo downstream_cx_destroy, Counter, Total destroyed connections downstream_cx_active, Gauge, Total active connections downstream_cx_length_ms, Timer, Connection length milliseconds - ssl.connection_error, Counter, Total SSL connection errors - ssl.handshake, Counter, Total SSL connection handshakes - ssl.no_certificate, Counter, Total SSL connections with no client certificate - ssl.fail_verify_san, Counter, Total SSL connections that failed SAN verification - ssl.fail_verify_cert_hash, Counter, Total SSL connections that failed certificate pinning verification - ssl.cipher., Counter, Total SSL connections that used + ssl.connection_error, Counter, Total TLS connection errors + ssl.handshake, Counter, Total TLS connection handshakes + ssl.no_certificate, Counter, Total TLS connections with no client certificate + ssl.fail_verify_san, Counter, Total TLS connections that failed SAN verification + ssl.fail_verify_cert_hash, Counter, Total TLS connections that failed certificate pinning verification + ssl.cipher., Counter, Total TLS connections that used diff --git a/docs/configuration/network_filters/client_ssl_auth_filter.rst b/docs/configuration/network_filters/client_ssl_auth_filter.rst index 1b99cb8e763a..2abcbe2de582 100644 --- a/docs/configuration/network_filters/client_ssl_auth_filter.rst +++ b/docs/configuration/network_filters/client_ssl_auth_filter.rst @@ -1,9 +1,9 @@ .. _config_network_filters_client_ssl_auth: -Client SSL authentication +Client TLS authentication ========================= -Client SSL authentication filter :ref:`architecture overview `. +Client TLS authentication filter :ref:`architecture overview `. .. code-block:: json @@ -45,7 +45,7 @@ ip_white_list Statistics ---------- -Every configured client SSL authentication filter has statistics rooted at +Every configured client TLS authentication filter has statistics rooted at *auth.clientssl..* with the following statistics: .. csv-table:: @@ -54,7 +54,7 @@ Every configured client SSL authentication filter has statistics rooted at update_success, Counter, Total principal update successes update_failure, Counter, Total principal update failures - auth_no_ssl, Counter, Total connections ignored due to no SSL + auth_no_ssl, Counter, Total connections ignored due to no TLS auth_ip_white_list, Counter, Total connections allowed due to the IP white list auth_digest_match, Counter, Total connections allowed due to certificate match auth_digest_no_match, Counter, Total connections denied due to no certificate match @@ -63,7 +63,7 @@ Every configured client SSL authentication filter has statistics rooted at Runtime ------- -The client SSL authentication filter supports the following runtime settings: +The client TLS authentication filter supports the following runtime settings: auth.clientssl.refresh_interval_ms Time in milliseconds between principal refreshes from the authentication service. Default is diff --git a/docs/intro/arch_overview/http_routing.rst b/docs/intro/arch_overview/http_routing.rst index b0e7c0b3619f..5184894eef0e 100644 --- a/docs/intro/arch_overview/http_routing.rst +++ b/docs/intro/arch_overview/http_routing.rst @@ -17,7 +17,7 @@ request. The router filter supports the following features: programmatically determine whether routing rules conflict with each other. For this reason we don’t recommend regex/slug routing at the reverse proxy level, however we may add support in the future depending on demand. -* SSL redirection at the virtual host level. +* TLS redirection at the virtual host level. * Path/host redirection at the route level. * Host rewriting. * Prefix rewriting. diff --git a/docs/intro/arch_overview/listeners.rst b/docs/intro/arch_overview/listeners.rst index fc33f332d592..14193f42dea5 100644 --- a/docs/intro/arch_overview/listeners.rst +++ b/docs/intro/arch_overview/listeners.rst @@ -12,7 +12,7 @@ Each listener is independently configured with some number of network level (L3/ `. When a new connection is received on a listener, the configured connection local filter stack is instantiated and begins processing subsequent events. The generic listener architecture is used to perform the vast majority of different proxy tasks that Envoy is -used for (e.g., :ref:`rate limiting `, :ref:`SSL client authentication +used for (e.g., :ref:`rate limiting `, :ref:`TLS client authentication `, :ref:`HTTP connection management `, MongoDB :ref:`sniffing `, raw :ref:`TCP proxy `, etc.). diff --git a/docs/intro/arch_overview/network_filters.rst b/docs/intro/arch_overview/network_filters.rst index bb23ed74926e..8848e10b401d 100644 --- a/docs/intro/arch_overview/network_filters.rst +++ b/docs/intro/arch_overview/network_filters.rst @@ -14,7 +14,7 @@ filters: connection and when it is about to send data to a downstream connection. The API for network level filters is relatively simple since ultimately the filters operate on raw -bytes and a small number of connection events (e.g., SSL handshake complete, connection disconnected +bytes and a small number of connection events (e.g., TLS handshake complete, connection disconnected locally or remotely, etc.). Filters in the chain can stop and subsequently continue iteration to further filters. This allows for more complex scenarios such as calling a :ref:`rate limiting service `, etc. Envoy already includes several network level filters that diff --git a/docs/intro/arch_overview/ssl.rst b/docs/intro/arch_overview/ssl.rst index e36649e1c697..846dec68d59d 100644 --- a/docs/intro/arch_overview/ssl.rst +++ b/docs/intro/arch_overview/ssl.rst @@ -1,20 +1,20 @@ .. _arch_overview_ssl: -SSL +TLS === -Envoy supports both :ref:`SSL termination ` in listeners as well as -:ref:`SSL origination ` when making connections to upstream +Envoy supports both :ref:`TLS termination ` in listeners as well as +:ref:`TLS origination ` when making connections to upstream clusters. Support is sufficient for Envoy to perform standard edge proxy duties for modern web -services as well as to initiate connections with external services that have advanced SSL -requirements (TLS1.2, SNI, etc.). Envoy supports the following SSL features: +services as well as to initiate connections with external services that have advanced TLS +requirements (TLS1.2, SNI, etc.). Envoy supports the following TLS features: -* **Configurable ciphers**: Each SSL listener and client can specify the ciphers that it supports. +* **Configurable ciphers**: Each TLS listener and client can specify the ciphers that it supports. * **Client certificates**: Upstream/client connections can present a client certificate in addition to server certificate verification. * **Certificate verification and pinning**: Certificate verification options include basic chain verification, subject name verification, and hash pinning. -* **ALPN**: SSL listeners support ALPN. The HTTP connection manager uses this information (in +* **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 currently supported for client connections. Listener support is likely to be added in the future. @@ -22,7 +22,7 @@ requirements (TLS1.2, SNI, etc.). Envoy supports the following SSL features: Underlying implementation ------------------------- -Currently Envoy is written to use openssl 1.0.2 as the SSL provider. Swapping in a different +Currently Envoy is written to use openssl 1.0.2 as the TLS provider. Swapping in a different provider in the future would not be difficult. .. _arch_overview_ssl_auth_filter: @@ -30,11 +30,11 @@ provider in the future would not be difficult. Authentication filter --------------------- -Envoy provides a network filter that performs SSL client authentication via principals fetched from +Envoy provides a network filter that performs TLS client authentication via principals fetched from a REST VPN service. This filter matches the presented client certificate hash against the principal list to determine whether the connection should be allowed or not. Optional IP white listing can also be configured. This functionality can be used to build edge proxy VPN support for web infrastructure. -Client SSL authentication filter :ref:`configuration reference +Client TLS authentication filter :ref:`configuration reference `. diff --git a/docs/intro/deployment_types/double_proxy.rst b/docs/intro/deployment_types/double_proxy.rst index 28b9e822ae41..329c3f2a2dc2 100644 --- a/docs/intro/deployment_types/double_proxy.rst +++ b/docs/intro/deployment_types/double_proxy.rst @@ -6,13 +6,13 @@ Service to service, front proxy, and double proxy The above diagram shows the :ref:`front proxy ` configuration alongside another Envoy cluster running as a *double proxy*. The idea behind the double proxy is that it is -more efficient to terminate SSL and client connections as close as possible to the user (shorter -round trip times for the SSL handshake, faster TCP CWND expansion, less chance for packet loss, +more efficient to terminate TLS and client connections as close as possible to the user (shorter +round trip times for the TLS handshake, faster TCP CWND expansion, less chance for packet loss, etc.). Connections that terminate in the double proxy are then multiplexed onto long lived HTTP/2 connections running in the main data center. In the above diagram, the front Envoy proxy running in region 1 authenticates itself with the front -Envoy proxy running in region 2 via SSL mutual authentication and pinned certificates. This allows +Envoy proxy running in region 2 via TLS mutual authentication and pinned certificates. This allows the front Envoy instances running in region 2 to trust elements of the incoming requests that ordinarily would not be trustable (such as the x-forwaded-for HTTP header). diff --git a/docs/intro/deployment_types/front_proxy.rst b/docs/intro/deployment_types/front_proxy.rst index f8f88697ac23..c4da63f5bcf2 100644 --- a/docs/intro/deployment_types/front_proxy.rst +++ b/docs/intro/deployment_types/front_proxy.rst @@ -9,7 +9,7 @@ The above diagram shows the :ref:`service to service ` chain mechanism allows filters to be written to perform different TCP proxy tasks and inserted into the main server. Filters have already been written to support various tasks such as raw :ref:`TCP proxy `, -:ref:`HTTP proxy `, :ref:`SSL client certificate +:ref:`HTTP proxy `, :ref:`TLS client certificate authentication `, etc. **HTTP L7 filter architecture:** HTTP is such a critical component of modern application @@ -93,7 +93,7 @@ shadowing. communication system, there is benefit in using the same software at the edge (observability, management, identical service discovery and load balancing algorithms, etc.). Envoy includes enough features to make it usable as an edge proxy for most modern web application use cases. This includes -:ref:`SSL ` termination, HTTP/1.1 and HTTP/2 :ref:`support +:ref:`TLS ` termination, HTTP/1.1 and HTTP/2 :ref:`support `, as well as HTTP L7 :ref:`routing `. **Best in class observability:** As stated above, the primary goal of Envoy is to make the network diff --git a/docs/landing_generated/index.html b/docs/landing_generated/index.html index 5cc78590b604..1cafc1a75d8b 100644 --- a/docs/landing_generated/index.html +++ b/docs/landing_generated/index.html @@ -109,7 +109,7 @@

HTTP L7 routing: Envoy supports advanced HTTP L7 routing primitives including redirection, virtual hosts, virtual clusters, matching on different request parameters, etc.

-

SSL: Envoy supports both SSL termination and initiation, client certificate +

TLS: Envoy supports both TLS termination and initiation, client certificate verification, and certificate pinning.

GRPC: Envoy has first class support for Google's GRPC framework.

MongoDB: Envoy contains a full MongoDB wire format parser that is used to gather diff --git a/docs/landing_source/source/localizable/index.html.erb b/docs/landing_source/source/localizable/index.html.erb index c40a7e975e1c..79a283922380 100644 --- a/docs/landing_source/source/localizable/index.html.erb +++ b/docs/landing_source/source/localizable/index.html.erb @@ -71,7 +71,7 @@ layout: layout

HTTP L7 routing: Envoy supports advanced HTTP L7 routing primitives including redirection, virtual hosts, virtual clusters, matching on different request parameters, etc.

-

SSL: Envoy supports both SSL termination and initiation, client certificate +

TLS: Envoy supports both TLS termination and initiation, client certificate verification, and certificate pinning.

GRPC: Envoy has first class support for Google's GRPC framework.

MongoDB: Envoy contains a full MongoDB wire format parser that is used to gather diff --git a/docs/operations/admin.rst b/docs/operations/admin.rst index 2d5139dd5704..9742f3903100 100644 --- a/docs/operations/admin.rst +++ b/docs/operations/admin.rst @@ -12,7 +12,7 @@ modify different aspects of the server. .. http:get:: /certs - List out all loaded SSL certificates, including file name, serial number, and days until + List out all loaded TLS certificates, including file name, serial number, and days until expiration. .. http:get:: /clusters