-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
SNI-based cert selection during TLS handshake #22036
Merged
ggreenway
merged 1 commit into
envoyproxy:main
from
LuyaoZhong:sni-based-cert-selection
Nov 30, 2022
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -114,21 +114,50 @@ Certificate selection | |
--------------------- | ||
|
||
:ref:`DownstreamTlsContexts <envoy_v3_api_msg_extensions.transport_sockets.tls.v3.DownstreamTlsContext>` support multiple TLS | ||
certificates. These may be a mix of RSA and P-256 ECDSA certificates. The following rules apply: | ||
certificates. These may be a mix of RSA and P-256 ECDSA certificates for multiple server name patterns. | ||
|
||
* Only one certificate of a particular type (RSA or ECDSA) may be specified. | ||
Certificate config/loading rules: | ||
|
||
* DNS SANs or Subject Common Name is extracted as server name pattern to match SNI during handshake. Subject Common Name is not used if DNS SANs are present in the certificate. | ||
* FQDN like "test.example.com" and wildcard like "\*.example.com" are valid at the same time, which will be loaded | ||
as two different server name patterns. | ||
* Only one certificate of a particular type (RSA or ECDSA) may be specified for each server name pattern. | ||
LuyaoZhong marked this conversation as resolved.
Show resolved
Hide resolved
|
||
* Non-P-256 server ECDSA certificates are rejected. | ||
* If the client supports P-256 ECDSA, a P-256 ECDSA certificate will be selected if one is present in the | ||
:ref:`DownstreamTlsContext <envoy_v3_api_msg_extensions.transport_sockets.tls.v3.DownstreamTlsContext>` | ||
and it is in compliance with the OCSP policy. | ||
* If the client only supports RSA certificates, a RSA certificate will be selected if present in the | ||
:ref:`DownstreamTlsContext <envoy_v3_api_msg_extensions.transport_sockets.tls.v3.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 :ref:`DownstreamTlsContext | ||
ggreenway marked this conversation as resolved.
Show resolved
Hide resolved
|
||
<envoy_v3_api_msg_extensions.transport_sockets.tls.v3.DownstreamTlsContext>`. | ||
* The selected certificate must adhere to the OCSP policy. If no | ||
such certificate is found, the connection is refused. | ||
|
||
Certificate selection rules: | ||
|
||
* If the client supports SNI, e.g. SNI is "test.example.com", it looks for a cert that exactly matches to the SNI. | ||
If the certificate adheres to the OCSP policy and matches to key type, it is selected for handshake. | ||
If the certificate adheres to the OCSP policy, but key type is RSA while client is ECDSA capable, it is marked as | ||
as the candidate and continues searching until a cert is selected with perfect match or certs exhausted. | ||
Comment on lines
+133
to
+134
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. Is this part gated by the full scan option? If so can you clarify? 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. No, this part is not gated by full scan option. |
||
Candidate will be selected for handshake if there is no perfect match. | ||
* If the client supports SNI, but no cert is selected from certs that exactly matches to SNI, it matches on wildcard server name. | ||
e.g. if SNI is "test.example.com", a certificate with "test.example.com" will be preferred over "\*.example.com". And wildcard | ||
matching only works for 1 level of depth, so "\*.com" will not be a match for "test.example.com". | ||
Afterwards, it execuates OCSP and key type checking on each cert which is the same as what happens after exact SNI matching. | ||
* If no cert is selected from certs that matches wildcard name, the candidate cert is selected for handshake if it is present. | ||
If there is no candidate, check :ref:`full_scan_certs_on_sni_mismatch <envoy_v3_api_field_extensions.transport_sockets.tls.v3.DownstreamTlsContext.full_scan_certs_on_sni_mismatch>`, | ||
go to full scan all certificates if it is enabled, otherwise pick the first certificate for handshake. | ||
* If the client does not provide SNI at all, go to full scan no matter :ref:`full_scan_certs_on_sni_mismatch <envoy_v3_api_field_extensions.transport_sockets.tls.v3.DownstreamTlsContext.full_scan_certs_on_sni_mismatch>` | ||
is false or true. | ||
* Full scan execuates OCSP and key type checking on each cert which is the same as described above in exact SNI matching. | ||
It falls back to the first cert in the whole list if there is no cert selected. | ||
* Currently only two kinds of key type are supported, RSA or ECDSA. If the client supports P-256 ECDSA, the P-256 ECDSA certificate | ||
is preferred over RSA. The certificate that it falls back to might result in a failed handshake. For instance, a client only supports | ||
RSA certificates and the certificate only support ECDSA. | ||
* The final selected certificate must adhere to the OCSP policy. If no such certificate is found, the connection is refused. | ||
|
||
.. note:: | ||
With the support of SNI-based certificate selection, it allows configuring large number of certificates for multiple hostnames. | ||
:ref:`full_scan_certs_on_sni_mismatch <envoy_v3_api_field_extensions.transport_sockets.tls.v3.DownstreamTlsContext.full_scan_certs_on_sni_mismatch>` | ||
is introduced to determine if we continue full scan on SNI mismatch when the client provides SNI. SNI mismatch contains two cases in this context, one is there is no cert that matches to SNI, | ||
another one is there are certs matches to SNI while OCSP policy fails on those certs. The :ref:`full_scan_certs_on_sni_mismatch <envoy_v3_api_field_extensions.transport_sockets.tls.v3.DownstreamTlsContext.full_scan_certs_on_sni_mismatch>` | ||
defaults to false, so full scan is disabled by default. The runtime flag ``envoy.reloadable_features.no_full_scan_certs_on_sni_mismatch`` | ||
can be used to override the default value of :ref:`full_scan_certs_on_sni_mismatch <envoy_v3_api_field_extensions.transport_sockets.tls.v3.DownstreamTlsContext.full_scan_certs_on_sni_mismatch>`. | ||
If full scan is enabled, it will look for the cert from the whole cert list on SNI mismatch, this could be a problem for a potential DoS attack because of O(n) complexity. | ||
|
||
|
||
Only a single TLS certificate is supported today for :ref:`UpstreamTlsContexts | ||
<envoy_v3_api_msg_extensions.transport_sockets.tls.v3.UpstreamTlsContext>`. | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I don't see documentation on the behavior when this setting is false and there's no SNI match.
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.
I didn't document too many details here, and would like to redirect users to doc
Multiple TLS certificates <arch_overview_ssl_cert_select>
. Should we document the behavior here as well?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.
No, redirecting to that page is fine, as long as it is documented somewhere.