为什么SSLSocketFactory缺少setEnabledCipherSuites？

Question

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

但是，SSLSocketFactory不提供setEnabledCipherSuites来配置密码列表一次，以提供后续套接字的首选项。

事实上，我认为让setEnabledCipherSuites成为SSLSocket的一部分真的会让wok流程变得复杂。例如，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这样的方法。

我试图为这种能力提出一个合理的安全工程原因，但我做不到。也许这是一个软件工程的原因。(我怀疑这有一个很好的理由，而我目前缺乏洞察力来看待它)。

为什么Java缺乏配置SSLSocketFactory的能力？这显然是一个设计决定，我试图理解为什么它是以牺牲库中相关部分的安全性为代价的。

Answer 1

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

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

但我不知道，我怀疑那些真正了解StackOverflow的少数人中没有一个会经常阅读。

这显然是一个设计决定，

从某种意义上说，是的。但这可能只是那些偶然或默认发生的设计决策之一。也可能是“他们”认为这个功能不会被使用。或者，这样做可能有一个合理的安全原因。

无论哪种方式，如果你对此有强烈的感觉，你可以建议这是一个Java增强(例如here)，或者开发一个补丁来实现你的增强并提交给OpenJDK团队。

如果你觉得没有动力提出/实现一个增强，那么要想得到“他们为什么要这样做”的答案，最好的方法就是自己去问“他们”。(请分享答案...)

Answer 2

JSSE允许通过安全属性定制密码和其他实现细节。参见Customizing JSSE。