Github user tellison commented on a diff in the pull request:
https://github.com/apache/spark/pull/7043#discussion_r33423170
--- Diff: core/src/main/scala/org/apache/spark/SSLOptions.scala ---
@@ -102,6 +106,36 @@ private[spark] case class SSLOptions(
}
}
+ /*
+ * The supportedAlgorithms set is a subset of the enabledAlgorithms that
+ * are supported by the current Java security provider for this protocol.
+ */
+ private val supportedAlgorithms: Set[String] = {
+ var context: Option[SSLContext] = Some(SSLContext.getDefault)
--- End diff --
I have removed the use of `Option`, but code to check if `protocol` is
empty would be bulky IMHO. Go ahead and change it as you see fit.
Yes, the change is to only use supported algorithms. This is logic already
done by Jetty (see [SslContextFactory.java]
(https://github.com/eclipse/jetty.project/blob/master/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java)
lines 1212 on) so is arguably unnecessary for the Spark HttpServer, but there
is no such logic in Netty and specifying unsupported ciphers causes the
handshake failure via Akka etc..
As I mentioned earlier, use of explicit protocols and cipher suites is
subject to change as the definition of 'secure' changes. SSLv3 is widely
deprecated since POODLE, so not a good choice for the sample config.
Restricting the protocol to use specific ciphers can ensure you only use secure
algorithms, but typically Java vendors are constantly amending the default list
in light of known vulnerabilities, and will update the negotiation set
accordingly. Since Spark's SSLSampleConfigs are explicit, they should be kept
under review too.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
