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

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

Answer 2

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

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

但我不知道，我怀疑真正知道的那些小伙伴都不会定期阅读StackOverflow。

这显然是一个设计决定，

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

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

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

为什么SSLSocketFactory缺少setEnabledCipherSuites？

2 个答案: