为什么SSLSocketFactory缺少setEnabledCipherSuites？
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这样的方法。
我正试图为（in）能力提出一个合理的安全工程理由，但我不能。 也许是决定软件工程的原因。 （我怀疑这是一个很好的理由，而且我目前缺乏洞察力）。
为什么Java缺乏配置SSLSocketFactory的能力？ 它显然是一个设计决策，我试图理解为什么它是以牺牲图书馆相关部分的安全性为代价的。
为什么Java缺乏配置SSLSocketFactory的能力？
可能是允许应用程序更改启用的密码套件被认为是一个坏主意。 您可能会认为这是一个平台安全问题而不是应用程序的责任，并且某些应用程序能够启用（或禁用）系统管理员已禁用/启用的套件将是一件坏事。
但我不知道，我怀疑没有一小部分人会真正知道经常阅读StackOverflow。
这显然是一个设计决定，
从某种意义上说，是的。 但它可能只是偶然或默认发生的设计决策之一。 或者可能是“他们”认为不会使用此function。 或者这样做可能有一个合理的安全原因。
无论哪种方式，如果您对此有强烈的兴趣，您可以将其建议为Java增强（例如此处 ），或者编写实现增强function的补丁并将其提交给OpenJDK团队。
如果你没有动力提出/实施增强function，那么得到“为什么要这样做”的答案的最好方法就是自己问“他们”。 （请分享答案……）