RinZ27 opened a new pull request, #56089: URL: https://github.com/apache/spark/pull/56089
### Problem Statement The current implementation of `SSLFactory` in `common/network-common` contains a significant security weakness where it defaults to a "trust-all" (credulous) `X509TrustManager` if a truststore is not explicitly provided in the configuration. This behavior silently invalidates SSL/TLS certificate validation, leaving Spark deployments vulnerable to Man-in-the-Middle (MITM) attacks on internal networking (Shuffle, RPC, etc.) when misconfigured. ### Proposed Changes I have refactored `SSLFactory.java` to eliminate the insecure `credulousTrustStoreManagers` fallback. Instead, the system now defaults to using the JVM's standard `TrustManagerFactory`, which utilizes the system's default truststore (e.g., `/etc/ssl/certs`). This ensures that certificate validation remains robust and secure by default, even when a custom truststore path is omitted. - Removed the insecure `credulousTrustStoreManagers` method. - Updated `trustStoreManagers` to initialize `TrustManagerFactory` with the default algorithm when no truststore file is provided. - Added a unit test in `SSLFactorySuite.java` to verify that `SSLFactory` correctly initializes using system defaults without a specific truststore. ### Technical Impact - **Security Hardening**: Prevents silent MITM vulnerabilities in networking components. - **Robustness**: Aligns Spark's SSL handling with standard Java security practices. - **Backward Compatibility**: Existing configurations with valid truststores are unaffected. Configurations relying on the system truststore will now correctly validate certificates instead of blindly trusting all. I've verified the changes locally and confirmed that `SSLFactory` continues to operate correctly under secure defaults. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
