为什么SSLSocketFactory缺少setEnabledCipherSuites？

Question

SSLSocketFactory提供getDefaultCipherSuites(在套接字上默认启用的getSupportedCipherSuites密码)和(如果需要,可以启用的密码).

但是,SSLSocketFactory不提供setEnabledCipherSuites配置密码列表一次以在后续套接字上提供首选项.

事实上,我认为制造setEnabledCipherSuites一部分SSLSocket非常复杂.例如,HttpsURLConnection没有提供getSocket,它确实打破了这个流程:

...
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, trustManager.getTrustManagers(), null);

HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();
connection.setSSLSocketFactory(context.getSocketFactory());

我认为同样可以说,SSLContext因为它有像getDefaultSSLParameters和的方法getSupportedSSLParameters.

我正试图为(in)能力提出一个合理的安全工程理由,但我不能.也许是决定软件工程的原因.(我怀疑这是一个很好的理由,而且我目前缺乏洞察力).

为什么Java缺乏配置的能力SSLSocketFactory？它显然是一个设计决策,我试图理解为什么它是以牺牲图书馆相关部分的安全性为代价的.

Answer 1

为什么Java缺乏配置SSLSocketFactory的能力？

允许应用程序更改已启用的密码套件可能被认为是一个坏主意。您可能会认为这是一个平台安全问题而不是应用程序责任，并且对于某些应用程序来说，能够启用（或禁用）系统管理员已禁用/启用的套件将是一件坏事。

但我不知道，而且我怀疑一小部分真正了解的人中没有人定期阅读 StackOverflow。

这显然是一个设计决定，

从某种意义上说，是的。但这可能只是偶然或默认发生的设计决策之一。或者可能是“他们”认为不会使用此功能。或者这样做可能有充分的安全理由。

无论哪种方式，如果您对此有强烈的感觉，您可以建议将其作为 Java 增强功能（例如，此处），或者编写一个实现您的增强功能的补丁并将其提交给 OpenJDK 团队。

如果您没有动力提出/实施增强功能，那么获得“他们为什么这样做”答案的最佳方法就是亲自询问“他们”。（并请分享答案......）