-
Notifications
You must be signed in to change notification settings - Fork 5.4k
tls: add options to validate SANs and send SNI for upstream hostname #36903
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
81b960e
2a3f7d2
4afa88e
9652d94
dc5cfd4
a39a863
d1ae94f
e1162e4
04bb7be
4699715
cc03ba4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -25,7 +25,7 @@ option (udpa.annotations.file_status).package_version_status = ACTIVE; | |
| // [#extension: envoy.transport_sockets.tls] | ||
| // The TLS contexts below provide the transport socket configuration for upstream/downstream TLS. | ||
|
|
||
| // [#next-free-field: 6] | ||
| // [#next-free-field: 8] | ||
| message UpstreamTlsContext { | ||
| option (udpa.annotations.versioning).previous_message_type = | ||
| "envoy.api.v2.auth.UpstreamTlsContext"; | ||
|
|
@@ -42,6 +42,26 @@ message UpstreamTlsContext { | |
| // SNI string to use when creating TLS backend connections. | ||
| string sni = 2 [(validate.rules).string = {max_bytes: 255}]; | ||
|
|
||
| // If true, replaces the SNI for the connection with the hostname of the upstream host, if | ||
| // the hostname is known due to either a DNS cluster type or the | ||
| // :ref:`hostname <envoy_v3_api_field_config.endpoint.v3.Endpoint.hostname>` is set on | ||
| // the host. | ||
| // | ||
| // See :ref:`SNI configuration <start_quick_start_securing_sni_client>` for details on how this | ||
| // interacts with other validation options. | ||
| bool auto_host_sni = 6; | ||
|
|
||
| // If true, replace any Subject Alternative Name validations with a validation for a DNS SAN matching | ||
| // the SNI value sent. Note that the validation will be against the actual requested SNI, regardless of how it | ||
| // is configured. | ||
| // | ||
| // For the common case where an SNI value is sent and it is expected that the server certificate contains a SAN | ||
| // matching that SNI value, this option will do the correct SAN validation. | ||
| // | ||
| // See :ref:`validation configuration <start_quick_start_securing_validation>` for how this interacts with | ||
| // other validation options. | ||
| bool auto_sni_san_validation = 7; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think I quite understand the semantics here. Perhaps we could have an example? |
||
|
|
||
| // If true, server-initiated TLS renegotiation will be allowed. | ||
| // | ||
| // .. attention:: | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -60,3 +60,11 @@ static_resources: | |
| typed_config: | ||
| "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext | ||
| sni: www.envoyproxy.io | ||
| common_tls_context: | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added this because I didn't want an example to not have a
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. probably we can use 1 config file and just highlight different parts - i can follow up with this |
||
| validation_context: | ||
| trusted_ca: | ||
| filename: certs/cacert.pem | ||
| match_typed_subject_alt_names: | ||
| - san_type: DNS | ||
| matcher: | ||
| exact: www.envoyproxy.io | ||
| Original file line number | Diff line number | Diff line change | ||
|---|---|---|---|---|
|
|
@@ -84,11 +84,22 @@ Firstly, you can ensure that the certificates are from a mutually trusted certif | |||
| :emphasize-lines: 8-11 | ||||
| :caption: :download:`envoy-demo-tls-validation.yaml <_include/envoy-demo-tls-validation.yaml>` | ||||
|
|
||||
| You can also ensure that the "Subject Alternative Names" for the cerficate match. | ||||
| You should also ensure that the Subject Alternative Names (SANs) for the certificate match. | ||||
|
|
||||
| This is commonly used by web certificates (X.509) to identify the domain or domains that a | ||||
| certificate is valid for. | ||||
|
|
||||
| For the most common case where the certificate should have a SAN matching the :ref:`SNI <start_quick_start_securing_sni_client>` | ||||
| which was sent, you can enable :ref:`auto_sni_san_validation <envoy_v3_api_field_extensions.transport_sockets.tls.v3.UpstreamTlsContext.auto_sni_san_validation>` | ||||
| and omit :ref:`match_typed_subject_alt_names <envoy_v3_api_field_extensions.transport_sockets.tls.v3.CertificateValidationContext.match_typed_subject_alt_names>` | ||||
| in the validation context. | ||||
|
|
||||
| To validate that a certificate has a SAN matching the downstream request ``host`` or ``:authority`` header, you can enable | ||||
| :ref:`auto_san_validation <envoy_v3_api_field_config.core.v3.UpstreamHttpProtocolOptions.auto_san_validation>`. | ||||
|
|
||||
| When multiple validation options are configured, ``auto_san_validation`` has the highest priority, followed by ``auto_sni_san_validation``, | ||||
| followed by ``match_typed_subject_alt_names``. | ||||
|
|
||||
| .. literalinclude:: _include/envoy-demo-tls-validation.yaml | ||||
| :language: yaml | ||||
| :linenos: | ||||
|
|
@@ -97,10 +108,6 @@ certificate is valid for. | |||
| :emphasize-lines: 6-7, 10-11 | ||||
| :caption: :download:`envoy-demo-tls-validation.yaml <_include/envoy-demo-tls-validation.yaml>` | ||||
|
|
||||
| .. note:: | ||||
|
|
||||
| If the "Subject Alternative Names" for a certificate are for a wildcard domain, eg ``*.example.com``, | ||||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This note didn't make sense; Envoy will correctly validate an expected SAN of
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it was quite a while ago when i added this - but i thought i added it after testing it out
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's documented in
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hmm - not sure - but im wondering if there are some circumstances where it doesnt work
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If there are, it's a bug and we should fix it.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if i get some time ill try and retry the steps i might have taken |
||||
| this is what you should use when matching with ``match_typed_subject_alt_names``. | ||||
|
|
||||
| .. note:: | ||||
|
|
||||
|
|
@@ -204,3 +211,16 @@ When connecting to an Envoy endpoint that is protected by ``SNI``, this must mat | |||
| :ref:`server_names <envoy_v3_api_field_config.listener.v3.FilterChainMatch.server_names>` set in the endpoint's | ||||
| :ref:`filter_chain_match <envoy_v3_api_msg_config.listener.v3.FilterChainMatch>`, as | ||||
| :ref:`described above <start_quick_start_securing_sni>`. | ||||
|
|
||||
| To derive SNI from a downstream HTTP header ``host`` or ``:authority``, turn on | ||||
| :ref:`auto_sni <envoy_v3_api_field_config.core.v3.UpstreamHttpProtocolOptions.auto_sni>` to override the fixed SNI in | ||||
| :ref:`UpstreamTlsContext <envoy_v3_api_msg_extensions.transport_sockets.tls.v3.UpstreamTlsContext>`. A custom header other than | ||||
| the ``host`` or ``:authority`` can also be supplied using the optional | ||||
| :ref:`override_auto_sni_header <envoy_v3_api_field_config.core.v3.UpstreamHttpProtocolOptions.override_auto_sni_header>` field. | ||||
|
|
||||
| To derive SNI from the host Envoy is connecting to, turn on :ref:`auto_host_sni | ||||
| <envoy_v3_api_field_extensions.transport_sockets.tls.v3.UpstreamTlsContext.auto_host_sni>`, which will use the hostname | ||||
| of the upstream endpoint. | ||||
|
|
||||
| When multiple options are configured, ``auto_sni`` has the highest priority, followed by ``auto_host_sni``, followed by | ||||
| the fixed ``sni``. | ||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this intended to relate to the auto_sni here:
https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/protocol.proto#config-core-v3-upstreamhttpprotocoloptions
And ditto for auto_san_validation vs auto_sni_san_validation?