-
Notifications
You must be signed in to change notification settings - Fork 586
add auto_sni and auto_san field in ClientTLSSettings #1773
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
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -952,6 +952,15 @@ message ClientTLSSettings { | |
|
|
||
| // SNI string to present to the server during TLS handshake. | ||
| string sni = 6; | ||
| // auto_sni and auto_san could automatically set the outbound SNI | ||
| // based on host/authority | ||
| // **NOTE:** auto_sni and auto_san fields are only applicable for HTTPs traffic | ||
| // when auto_sni field set as true, it will override the sni set above. | ||
| // Additional context: | ||
| // https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/protocol.proto#envoy-v3-api-field-config-core-v3-upstreamhttpprotocoloptions-auto-sni | ||
| // https://github.com/istio/istio/issues/27847 | ||
| bool auto_sni = 8; | ||
|
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. Unless I missed something, the RFC does require that a HTTPs client sets the SNI this way. It is a bug to not do so - I don't think we need an API to indicate we should be compatible with the RFC. I'm not sure what auto_san does in this context - but if it's about following the RFC it is also redundant. A bigger issue is that the default value of bool in proto is false - meaning that if user doesn't include the new fields, the default behavior would be non-standard. I don't think the API need a 'non-standard' mode - and for upgrade issues we can use an temporary internal env variable like we did in the past, not a long-term supported API change. 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. @costinm RFC does not mandate HTTPS client to set SNI (it can be not set at all) / verify SAN in this way, RFC 2818 says
In most of Istio service-to-service communication in mTLS, we don't set SNI or verify SAN in this way, but we use SVID to perform the identity verification. This only need to be set for certain egress cases. 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. @lizan RFC 7540 said:
RFC 2818 is too old and no longer reflects reality. 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. Also I would note we DO always set an SNI. We just set our weird internal format (I think) |
||
| bool auto_san = 9; | ||
| } | ||
|
|
||
| // Locality-weighted load balancing allows administrators to control the | ||
|
|
||
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.
Document this only works with HTTPS traffic, and when auto_sni is true it will override the sni set above.
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.
added notes on them