[SPARK-54293][SQL] Disable SNI host check in ThriftHttpCLIService#55308
Open
yadavay-amzn wants to merge 2 commits intoapache:masterfrom
Open
[SPARK-54293][SQL] Disable SNI host check in ThriftHttpCLIService#55308yadavay-amzn wants to merge 2 commits intoapache:masterfrom
yadavay-amzn wants to merge 2 commits intoapache:masterfrom
Conversation
1a3a880 to
1f7e24c
Compare
Author
|
@LuciferYang Could you take a look when you get a chance? Thanks! |
LuciferYang
reviewed
May 5, 2026
| Arrays.toString(sslContextFactoryServer.getExcludeProtocols())); | ||
| sslContextFactoryServer.setKeyStorePath(keyStorePath); | ||
| sslContextFactoryServer.setKeyStorePassword(keyStorePassword); | ||
| // SPARK-54293: Disable SNI host check, which defaults to true since Jetty 10. |
Member
|
can we follow SPARK-56528 (#55396) to make it configurable? |
added 2 commits
May 5, 2026 20:51
Disable SNI host check in ThriftHttpCLIService's Jetty SSL connector, consistent with the fix applied to JettyUtils.scala in SPARK-45522. Since Jetty 10, SniHostCheck defaults to true. This was fixed in the Spark UI server but not in ThriftHttpCLIService, which also creates a Jetty server with SSL support. Note: RestSubmissionServer (also mentioned in the JIRA) does not have SSL support, so it does not need this fix.
Address review feedback from @pan3793 (PR apache#55308): follow the pattern established in SPARK-56528 and make the SNI host check configurable rather than unconditionally disabled. Introduces spark.sql.hive.thriftServer.http.sniHostCheckEnabled (default: false, preserving the behavior from the first commit on this branch). Operators who want stricter host checking for security can opt in by setting the flag to true.
1f7e24c to
63c708a
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What changes were proposed in this pull request?
Disable SNI host check in
ThriftHttpCLIServiceby adding aSecureRequestCustomizerwithsetSniHostCheck(false)to the Jetty SSL connector configuration.This is the same fix that was applied to
JettyUtils.scalain SPARK-45522 when Spark upgraded from Jetty 9 to Jetty 10, but was missed forThriftHttpCLIService.Why are the changes needed?
Since Jetty 10,
SniHostCheckdefaults totrue. This was disabled in the Spark UI server (SPARK-45522) but not inThriftHttpCLIService, which also creates a Jetty server with SSL support. Without this fix, the Hive Thrift HTTP server may reject HTTPS connections when the SNI hostname does not match the certificate.Note on
RestSubmissionServer: The JIRA also mentionsRestSubmissionServer, but after reviewing the code, it has no SSL support — it only creates plain HTTP connectors. The SNI host check only applies to HTTPS, soRestSubmissionServerdoes not need this fix.Does this PR introduce any user-facing change?
No. This restores the pre-Jetty 10 behavior where SNI host check was not enforced.
How was this patch tested?
Added
ThriftHttpCLIServiceSuitewith two tests:SecureRequestCustomizer.sniHostCheckset tofalse.sniHostCheckistrue, confirming the bug.Was this patch authored or co-authored using generative AI tooling?
Yes